Bug 990580 - BPMS should not use local .m2 repository
BPMS should not use local .m2 repository
Status: CLOSED WONTFIX
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity high
: DR6
: ---
Assigned To: Jervis Liu
Lukáš Petrovický
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-31 09:36 EDT by Jiri Svitak
Modified: 2015-06-01 21:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-11 12:17:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Svitak 2013-07-31 09:36:33 EDT
BPMS should use only the local repository, which is part of the container (ie. in jboss-eap-6.1/bin/repository). But it also installs the artifacts into local system .m2 repository. This is undesired.

This behavior affects other instances, for example take a look startup log of a fresh jbpm 6 cr1 instance:
21:32:16,144 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (MSC service thread 1-1) KieModule was added:ZipKieModule[ ReleaseId=com.bpms.flood:bpms-perf:1.0.0.Finalfile=/home/jsvitak/.m2/repository/com/bpms/flood/bpms-perf/1.0.0.Final/bpms-perf-1.0.0.Final.jar]

BPMS should work only with its own dedicated repository in container.

Affected versions are both BPMS 6 DR6 and jBPM 6 CR1.
Comment 1 Jervis Liu 2013-08-05 02:20:27 EDT
This is expected behavior. 

Guvnor M2 repo is a remote maven repository: 

"Remote repositories refer to any other type of repository, accessed by a variety of protocols such as file:// and http://. These repositories might be a truly remote repository set up by a third party to provide their artifacts for downloading (for example, repo.maven.apache.org and uk.maven.org house Maven's central repository). Other "remote" repositories may be internal repositories set up on a file or HTTP server within your company, used to share private artifacts between development teams and for releases."

On the other hand, no matter which remote repository is configured for you project, you always have a local repository (.m2) which is used as a cache of the remote downloads and temporary builds etc.
Comment 2 Jervis Liu 2013-08-12 21:21:46 EDT
Any comments? As using local .m2 repo is expected maven behavior, I would like to close this issue as "not a bug" if there is no objection.
Comment 3 Jiri Svitak 2013-08-13 05:48:35 EDT
Before closing the bug, can you explain the message in bug description, which comes from the server log?

I see two situations here:
1.) The fresh BPMS instance tried to load deployment unit from ~/.m2 repository, because it was somehow configured in system /tmp. In this case the bug can be closed and the solution will arrive with fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=990575

2.) The fresh BPMS automatically looks into ~/.m2 for deployment units, which is undesired behavior and BPMS should limit its usage only to Guvnor M2 repo. "using local .m2 repo is expected maven behavior" - this is true, but AFAIK you can override that and use a different repo, am I correct?

The point is that fresh(vanilla) installation of BPMS should work always the same, independent on previous or other BPMS installations on the same machine. So running the fresh instance means there will be no such messages in server log.

It looks like the first option is true, can you confirm that? Thanks.
Comment 4 Jervis Liu 2013-08-15 05:04:27 EDT
"2.) The fresh BPMS automatically looks into ~/.m2 for deployment units, which is undesired behavior and BPMS should limit its usage only to Guvnor M2 repo. "using local .m2 repo is expected maven behavior" - this is true, but AFAIK you can override that and use a different repo, am I correct?"

- For maven build to work, it always need a local repository as a cache of the remote downloads and temporary builds. Guvnor m2 repo is not intended to replace maven local repo. Instead, Guvnor m2 repo is a remote maven repo that provides artifacts for downloading, similar as jboss repository or other public repository (but Guvnor m2 repo is a private remote maven rep).
Comment 5 Jiri Svitak 2013-08-15 05:21:27 EDT
Thanks for explanation.

However I still did not get the explanation and confirmation about this log message:
21:32:16,144 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (MSC service thread 1-1) KieModule was added:ZipKieModule[ ReleaseId=com.bpms.flood:bpms-perf:1.0.0.Finalfile=/home/jsvitak/.m2/repository/com/bpms/flood/bpms-perf/1.0.0.Final/bpms-perf-1.0.0.Final.jar]

How the fresh (vanilla) installation of BPMS knows about these artifacts, which were installed by previous instance of BPMS? Can you confirm that this information is stored and loaded in system /tmp dir?
Comment 6 Jervis Liu 2013-08-18 23:44:41 EDT
maven always looks for artifacts from the local repository first. It will looks for artifacts further from remote repositories if it does not find the artifact from the local repo. What happened is that your previous brms installation installed bpms-perf-1.0.0.Final.jar into maven local repo. As this is not a snapshot version (bpms-perf-1.0.0.Final.jar), maven needs not to look further in other remote repos.
Comment 7 Jervis Liu 2013-08-26 00:39:08 EDT
"21:32:16,144 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (MSC service thread 1-1) KieModule was added:ZipKieModule[ ReleaseId=com.bpms.flood:bpms-perf:1.0.0.Finalfile=/home/jsvitak/.m2/repository/com/bpms/flood/bpms-perf/1.0.0.Final/bpms-perf-1.0.0.Final.jar]

How the fresh (vanilla) installation of BPMS knows about these artifacts, which were installed by previous instance of BPMS? Can you confirm that this information is stored and loaded in system /tmp dir?"

This is what happened: 

Your previous brms installation installed bpms-perf-1.0.0.Final.jar into maven local repo as part of maven build process (maven always installs artifacts into local repo and use this local repo as a cache). Your new BRMS installation found bpms-perf-1.0.0.Final.jar from maven local repo. Maven does not need to look for bpms-perf-1.0.0.Final.jar from any other maven remote repos. This is because bpms-perf-1.0.0.Final.jar is not a snapshot version, which means even if maven finds bpms-perf-1.0.0.Final.jar from a remote repo, bpms-perf-1.0.0.Final.jar will be exactly same as the bpms-perf-1.0.0.Final.jar found in local repo.
Comment 8 Jiri Svitak 2013-08-28 03:39:15 EDT
Thanks for further clarification, but there are still few things unclear:

"Your new BRMS installation found bpms-perf-1.0.0.Final.jar from maven local repo."
What is the key that BRMS used to load exactly this artifact? Is it because it contained kmodule.xml? Was the name of the artifact saved somewhere? I was interested in the key how the artifact was loaded. Because if there is no key, then BRMS would load all .jar artifacts from the repository.

"This is because bpms-perf-1.0.0.Final.jar is not a snapshot version, which means even if maven finds bpms-perf-1.0.0.Final.jar from a remote repo, bpms-perf-1.0.0.Final.jar will be exactly same as the bpms-perf-1.0.0.Final.jar found in local repo."
I understand, but remote repo in my fresh BRMS installation was empty, so there could not be any match. So this sentence does not explain what happened.

My point is to make sure that BRMS does not depend on content of /tmp or other external configuration locations.
Comment 9 Jervis Liu 2013-08-28 20:56:46 EDT
"What is the key that BRMS used to load exactly this artifact? Is it because it contained kmodule.xml? Was the name of the artifact saved somewhere? I was interested in the key how the artifact was loaded. Because if there is no key, then BRMS would load all .jar artifacts from the repository." 

- GAV is the key. I dont know who is using bpms-perf-1.0.0.Final.jar, but there must be some components in your system depend on bpms-perf-1.0.0.Final.jar. 

"I understand, but remote repo in my fresh BRMS installation was empty, so there could not be any match. So this sentence does not explain what happened."

- Yes, the remote repo (Guvnor M2 repo) in your fresh BRMS installation is empty. But your local maven repo (.m2) is not empty, it contains the bpms-perf-1.0.0.Final.jar which was installed by your previous BRMS installation.
Comment 10 Jervis Liu 2013-09-10 06:12:28 EDT
Jiri, can we close this issue now?
Comment 11 Jiri Svitak 2013-09-11 12:17:33 EDT
Jervis,

I have looked again on this issue and have to clear a few things.

1.) I have not received an explanation how the fresh BPMS instance could know the GAV of a project created by previous BPMS instances. My suspicion was system /tmp, but this was not confirmed nor refuted.

2.) I have realized that title of this bug is misleading and you answers were related to title of this bug. Unfortunately we have not found an explanation.

Since this bug does not break any functionality and it just produces confusing messages, I am closing this bug.
Comment 12 Jervis Liu 2013-09-18 05:33:42 EDT
Hi Jiri, see my comments below, hope this will answer your question:

"1.) I have not received an explanation how the fresh BPMS instance could know the GAV of a project created by previous BPMS instances. My suspicion was system /tmp, but this was not confirmed nor refuted."

- Your previous brms installation installed bpms-perf-1.0.0.Final.jar into local maven repo as part of maven build process (maven always installs artifacts into local maven  repo and use this local maven repo as a cache). Your new BRMS installation found bpms-perf-1.0.0.Final.jar from local maven repo.

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