Red Hat Bugzilla – Bug 1017283
jBPM requires artifacts to be present in .m2/repository instead of SRAMP repository
Last modified: 2014-02-06 10:27:09 EST
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):
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.
Exception thrown: Cannot find KieModule: org.overlord.dtgov:dtgov-workflows:1.0.1.Final-redhat-4
More info on this can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1016474
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?
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?
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?
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.
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!
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.
We now read the workflows from S-RAMP using the S-RAMP client, rather then using the Kie/Maven integration.
Verified in FSW 6.0.0.ER8