Bug 1017283 - jBPM requires artifacts to be present in .m2/repository instead of SRAMP repository
jBPM requires artifacts to be present in .m2/repository instead of SRAMP repo...
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: DT Governance (Show other bugs)
6.0.0 GA
Unspecified Unspecified
medium Severity high
: ER7
: 6.0.0
Assigned To: Kurt T Stam
Jiri Pechanec
Depends On:
  Show dependency treegraph
Reported: 2013-10-09 10:53 EDT by George Varsamis
Modified: 2014-02-06 10:27 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-06 10:27:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker DTGOV-38 Major Closed Cleanup work on DTGov-24 2014-09-08 03:24:11 EDT

  None (edit)
Description George Varsamis 2013-10-09 10:53:04 EDT
Description of problem:
During deployment of DTGOV (SOA 6) workflow jbpm looks for the artifact on the local .m2/repository instead of the S-RAMP repository. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run the SOA6 installer and install the distribution (http://dev138.mw.lab.eng.bos.redhat.com/candidate/soa-6.0.0-ER4/)
2.cd into the install dir of the distribution, then cd into the data directory and run: mvn deploy
3.Start the server.

Actual results:
Exception thrown: Cannot find KieModule: org.overlord.dtgov:dtgov-workflows:1.0.1.Final-redhat-4

Expected results:
No exceptions

Additional info:

More info on this can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1016474
Comment 1 George Varsamis 2013-10-09 10:56:20 EDT
Another issue that I have noticed, is that if the user decides to install the artifacts in any location other than .m2/repository then jbpm fails to see the artifacts as it expects them to be found on .m2/repository.

This is restrictive. Maybe we could make the location of the repository a configuration option?
Comment 3 Kris Verlaenen 2013-10-14 09:09:41 EDT
When resolving a kjar through maven, it will indeed look into the local repository.  You can however also add external repos, which will be contacted in case the artefact is not found on the local maven repo (I believe using something like MavenRepository.addExtraRepository(..)).  This will first download the artefact from the remote repo to the local repo, after which it will be resolved from the local repo (which is how maven always works I believe).  So not sure "instead of" is the correct phrasing, both can be combined imho.

It is true that currently it will always try to use ~/.m2/repository, and for example not take into account if the local repo is placed elsewhere using ~/.m2/settings.xml.  I do agree that this is a limitation that we should try to improve.  Mario, is this something you can take a look at?
Comment 4 Mario Fusco 2013-10-15 03:23:51 EDT
Yesterday I closed this jira issue https://issues.jboss.org/browse/DROOLS-298 so now it also take into account what you have in your settings.xml files, both in the maven configuration folder and in the users's .m2 folder. 

Is this enough to consider this issue resolved?
Comment 5 Kris Verlaenen 2013-10-15 09:28:04 EDT
George, assuming the issue with location / configuring the local M2 repo is solved, is there anything that still needs to be addressed?  If so, could you elaborate?

Lowering priority until we have more clarity.
Comment 6 George Varsamis 2013-10-15 09:36:52 EDT
This is something that Gary Brown or Kevin Conner can comment with regards to the applicability of the fix.

With regards to the second issue, of not looking in the settings.xml is concerned, the current fix satisfies this requirement!
Comment 7 kconner 2013-10-15 10:35:19 EDT
We are looking to move away from deploying the workflows into the local .m2 repository as we lose control over them.  Kurt is working on updating this to use the Kie APIs rather than relying on maven.
Comment 9 Kurt T Stam 2013-10-22 13:15:18 EDT
We now read the workflows from S-RAMP using the S-RAMP client, rather then using the Kie/Maven integration.
Comment 10 Stefan Bunciak 2014-01-06 09:58:26 EST
Verified in FSW 6.0.0.ER8

Note You need to log in before you can comment on or make changes to this bug.