[jira] [Created] (MNG-7348) maven.artifact.threads not respected in maven parallel builds.
Kari J. Niemi created MNG-7348:
--
Summary: maven.artifact.threads not respected in maven parallel
builds.
Key: MNG-7348
URL: https://issues.apache.org/jira/browse/MNG-7348
Project: Maven
Issue Type: Bug
Affects Versions: 3.6.3
Reporter: Kari J. Niemi
maven.artifact.threads=1 is not respected in maven parallel builds. Maven seems
to do the downloads inside the BuilderThreads when using the 1 as the value -
so with multiple build threads ("-T 1C" for example), downloads will be done in
as many threads as there are BuildThreads. I confirmed this by polling the
stack traces of the maven process: I saw that the Resolver/Wagon/aether was in
the stack trace of multiple BuilderThreads at the same time, and there were no
"resolver-x" threads at all.
The documentation for maven.artifact.thread says "Number of threads to use for
uploading/downloading.": [https://maven.apache.org/resolver/configuration.html]
I suppose the issue is around here:
[https://github.com/apache/maven/blob/maven-3.6.3/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java#L106-L115]
I'm really not a java expert, and actually hope to be wrong about it - but to
me it seems that the "maven.artifact.threads=1"-case is getting executed in the
same thread, and therefore there will be as many downloading threads as there
are BuildThreads?
( Background: this was the latest and maybe last miserable try to work around
the bugs in parallel artifact downloads... which lead to builds failing and
corrupted stuff in local maven repository )
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MWAR-448) packaging dependencies fails with "mvn install" but not "mvn package"
Kari J. Niemi created MWAR-448: -- Summary: packaging dependencies fails with "mvn install" but not "mvn package" Key: MWAR-448 URL: https://issues.apache.org/jira/browse/MWAR-448 Project: Maven WAR Plugin Issue Type: Bug Affects Versions: 3.3.2 Environment: maven 3.6.3 ( later versions have bugs which we can't take in) Reporter: Kari J. Niemi I think we discovered a minor odd difference with war-packaging between "mvn package" or "mvn install". We would expect that only difference between the two is that the latter also installs the produced stuff in the local maven repository. We are packaging a few jars to a war. We have a parent pom with some modules, and that is defined as a dependency in the pom.xml that produces a war-package. Like this: my-war-thingie:pom.xml (packaging:war) * dependency: some-parent some-parent:pom.xml (packaging:pom) * module1 (packaging:jar) * module2 (packaging:jar) Earlier we had a different structure and everything was just fine: we did not the have the child-modules but the parent-pom produced the jar. When we changed the structure to the one described above: our CI was still OK, some developers building OK as well -but some developers had failing maven builds because of missing "some-parent.jar". It was bit of devastating hunt, but finally we discovered that "mvn package" was building OK, but "mvn install" looks for "some-parent.jar". We don't actually mind if the above scenario would fail in both cases, or if it was successful - we would just expect that it works the same way for both. If this is intended behaviour, it would be nice to have it documented. FWIW: in our case, we anyway wanted to define direct dependencies from the war-packaging to the child-modules. So actually, we are OK wih our builds already. But the difference caused so may doubts about our builds reproducibility - and also, it seems like a bug - so I wanted to be good citizen and report the problem. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MWAR-448) packaging dependencies fails with "mvn install" but not "mvn package"
[ https://issues.apache.org/jira/browse/MWAR-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kari J. Niemi updated MWAR-448: --- Description: I think we discovered a minor odd difference with war-packaging between "mvn package" or "mvn install". We would expect that only difference between the two is that the latter also installs the produced stuff in the local maven repository. We are packaging a few jars to a war. We have a parent pom with some modules, and that is defined as a dependency in the pom.xml that produces a war-package. Like this: my-war-thingie:pom.xml (packaging:war) * dependency: some-parent some-parent:pom.xml (packaging:pom) * module1 (packaging:jar) * module2 (packaging:jar) Earlier we had a different structure and everything was just fine: we did not the have the child-modules but the parent-pom produced the jar. When we changed the structure to the one described above: our CI was still OK, some developers building OK as well -but some developers had failing maven builds because of missing "some-parent.jar". It was bit of devastating hunt, but finally we discovered that "mvn package" was building OK, but "mvn install" looks for "some-parent.jar". We don't actually mind if the above scenario would fail in both cases, or if it was successful - we would just expect that it works the same way for both. If this is intended behaviour, it would be nice to have it documented. FWIW: in our case, we anyway wanted to define direct dependencies from the war-packaging to the child-modules. So actually, we are OK wih our builds already. But the difference caused so may doubts about our builds reproducibility - and also, it seems like a bug - so I wanted to be good citizen and report the problem. Edit: further note from our troubleshooting sessions: we don't have the "type" for the dependency at all in my-war-thingie:pom.xml. Yesterday, we did experiment setting the type as "pom" -and as a consequence, both "mvn package" and "mvn install" were successful. The default as we know, should/would be "jar". Maybe the missing dependency type is for some odd reason resolved differently for "maven package" and "maven install"? was: I think we discovered a minor odd difference with war-packaging between "mvn package" or "mvn install". We would expect that only difference between the two is that the latter also installs the produced stuff in the local maven repository. We are packaging a few jars to a war. We have a parent pom with some modules, and that is defined as a dependency in the pom.xml that produces a war-package. Like this: my-war-thingie:pom.xml (packaging:war) * dependency: some-parent some-parent:pom.xml (packaging:pom) * module1 (packaging:jar) * module2 (packaging:jar) Earlier we had a different structure and everything was just fine: we did not the have the child-modules but the parent-pom produced the jar. When we changed the structure to the one described above: our CI was still OK, some developers building OK as well -but some developers had failing maven builds because of missing "some-parent.jar". It was bit of devastating hunt, but finally we discovered that "mvn package" was building OK, but "mvn install" looks for "some-parent.jar". We don't actually mind if the above scenario would fail in both cases, or if it was successful - we would just expect that it works the same way for both. If this is intended behaviour, it would be nice to have it documented. FWIW: in our case, we anyway wanted to define direct dependencies from the war-packaging to the child-modules. So actually, we are OK wih our builds already. But the difference caused so may doubts about our builds reproducibility - and also, it seems like a bug - so I wanted to be good citizen and report the problem. > packaging dependencies fails with "mvn install" but not "mvn package" > - > > Key: MWAR-448 > URL: https://issues.apache.org/jira/browse/MWAR-448 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 3.3.2 > Environment: maven 3.6.3 ( later versions have bugs which we can't > take in) >Reporter: Kari J. Niemi >Priority: Minor > > I think we discovered a minor odd difference with war-packaging between "mvn > package" or "mvn install". We would expect that only difference between the > two is that the latter also installs the produced stuff in the local maven > repository. > > We are packaging a few jars to a war. We have a parent pom with some modules, > and that is defined as a dependency in the pom.xml that produces a > war-package. Like this: > my-war-thingie:pom.xml (packaging:war) > * dependency: some-parent > some-parent:pom.xml (packaging:pom) > * module1 (packaging:jar) > * module2 (packaging:jar)
[jira] Commented: (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=267511#action_267511
]
Kari J. Niemi commented on MNG-4996:
It seems I've forgotten to specifically mention that the jbi-maven-plugin is
not yet marked as thread-safe and is causing a lot of warnings in the build
log. I probably thought that it's not causing the problem because (as far as I
know) it's mostly just binding the "basic" maven plugins to different phases.
But actually, I really don't know. And actually I don't know which versions of
the "basic" maven plugins(depensurefire/ it uses... maybe it's binding some
specific(older) versions and not using the ones defined in our
pom.xmls...(?)... h... actually I propably thought the pluginArtifactMap
there would reveal this...
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrator
[jira] Created: (MNG-5100) Hints for setting mem options of maven&plug-ins (for parallel builds)
Hints for setting mem options of maven&plug-ins (for parallel builds) - Key: MNG-5100 URL: http://jira.codehaus.org/browse/MNG-5100 Project: Maven 2 & 3 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 3.0.3 Reporter: Kari J. Niemi (I enabled parallel builds of maven3 for my project in CI server, it was running quite nicely giving me much faster builds for a multi-module build. But... it brought our CI server on it's knees, other projects suffered from this and the CI build server admin bashed me to get back to serial build :D... oh, he's such a nice guy :D...) I did some googling around and found out that in Linux, forking new processes may be extremely slow in case the parent that forks, has a great memory print. Well, in the past I had (of course) optimized my build for maven2 by throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting both Xms and Xms to the same huge value, not forgetting the MaxPermSize and PermSize. I suppose this, together with the linux forking "feature", might cause the extreme cpu load? And of course the CI server process itself has an even bigger memory print, times ten or something, fortunately I suppose it's not doing so much forking... I suppose the memory tuning should/could be done quite differently when using parallel build feature because the mem is then used in the forked processes which are smaller? So in parallel build I might set those mem options pretty low, I guess? And also I could be setting "-client"-mode manually -because otherwise jvm would think it should be running in server mode (due to running in server HW. Actually I don't quite understand why jvm anyway decides based on HW whether it should be running in server or client mode - there's no such relation -not every jvm running on server HW is really a server process...) Is there anything that we could be improve in maven/maven documentation in this respect? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5100) Hints for setting mem options of maven&plug-ins (for parallel builds)
[ http://jira.codehaus.org/browse/MNG-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268239#action_268239 ] Kari J. Niemi commented on MNG-5100: ( If in doubt about forking being slow in Linux: http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html http://www.google.fi/search?q=fork+is+so+slow+on+Linux+is+because+the+default+page+size+is+4k&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fi:official&client=firefox-a https://github.com/rtomayko/posix-spawn#readme http://stackoverflow.com/questions/2731531/faster-forking-of-large-processes-on-linux/2874009#2874009 http://kirkwylie.blogspot.com/2008/11/linux-fork-performance-redux-large.html http://kirkwylie.blogspot.com/2008/10/linux-less-terrible-choice-for-java.html http://kirkwylie.blogspot.com/2008/09/solaris-10-terrible-choice-for-java.html#disqus_thread ) > Hints for setting mem options of maven&plug-ins (for parallel builds) > - > > Key: MNG-5100 > URL: http://jira.codehaus.org/browse/MNG-5100 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Documentation: Guides >Affects Versions: 3.0.3 >Reporter: Kari J. Niemi > > (I enabled parallel builds of maven3 for my project in CI server, it was > running quite nicely giving me much faster builds for a multi-module build. > But... it brought our CI server on it's knees, other projects suffered from > this and the CI build server admin bashed me to get back to serial build > :D... oh, he's such a nice guy :D...) > I did some googling around and found out that in Linux, forking new processes > may be extremely slow in case the parent that forks, has a great memory > print. Well, in the past I had (of course) optimized my build for maven2 by > throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting > both Xms and Xms to the same huge value, not forgetting the MaxPermSize and > PermSize. I suppose this, together with the linux forking "feature", might > cause the extreme cpu load? And of course the CI server process itself has an > even bigger memory print, times ten or something, fortunately I suppose it's > not doing so much forking... > I suppose the memory tuning should/could be done quite differently when using > parallel build feature because the mem is then used in the forked processes > which are smaller? So in parallel build I might set those mem options pretty > low, I guess? And also I could be setting "-client"-mode manually -because > otherwise jvm would think it should be running in server mode (due to running > in server HW. Actually I don't quite understand why jvm anyway decides based > on HW whether it should be running in server or client mode - there's no such > relation -not every jvm running on server HW is really a server process...) > Is there anything that we could be improve in maven/maven documentation in > this respect? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-143) Maven3 parallel build fails occasionally for classpath problems.
Maven3 parallel build fails occasionally for classpath problems.
Key: MCOMPILER-143
URL: http://jira.codehaus.org/browse/MCOMPILER-143
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: maven 3.0.1, maven 3.0
Reporter: Kari J. Niemi
In a multimodule (>120 modules) maven build, the compiler plug-in would seem to
fail in creating a correct class-path every now and then.
Instead of this entry in maven -X logs for a single module build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator -->
..
[DEBUG] (f) classpathElements =
[/home/karniemi/"mymodulepath"/target/classes,
/home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
/home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
/home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
/home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
/home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
/home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
every now and then I get this in the parallel build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator -->
...
[DEBUG] (f) classpathElements = [/home/karniemi/"mymodulepath"/target/classes]
And of course the compilation fails because none of the dependencies are added
to the classpath. Sometimes it goes fine in the multi-module build, but every
now and then it fails for this.
In both maven runs I can see that the dependencies are resolved fine:
--
[DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
[DEBUG]junit:junit:jar:4.7:test
[DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
[DEBUG]
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
[DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
[DEBUG]
org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
(scope managed from compile) (version managed from 1.1.0)
[DEBUG]
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
[DEBUG]log4j:log4j:jar:1.2.14:provided
---
The pluginArtifactMap looks like this:
[DEBUG] (s) pluginArtifactMap =
{org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
junit:junit=junit:junit:jar:3.8.1:compile,
org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
I'm really using jbi-maven-plugin for most of the modules, and that plugin
binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4982) Differences into transitive dependency scope resolution between Maven 3 and Maven 2
[
http://jira.codehaus.org/browse/MNG-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252915#action_252915
]
Kari J. Niemi commented on MNG-4982:
In both dependency tree logs org.apache.xmlgraphics:fop:jar:1.0 has the scope
"provided". Hmmm... or is there something wrong with my eyes?
> Differences into transitive dependency scope resolution between Maven 3 and
> Maven 2
> ---
>
> Key: MNG-4982
> URL: http://jira.codehaus.org/browse/MNG-4982
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 10:58:10+1000)
> Java version: 1.6.0_17, vendor: Sun Microsystems Inc.
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
> Java version: 1.6.0_17
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Renato Garcia
> Attachments: test-projects.zip
>
>
> I'm getting different transitive dependency scope resolution when building
> with Maven 3. Transitive dependencies from a *provided* scope should be
> resolved to *provided* according to the
> [docs|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope],
> but it is resolving to *compile* as shown below. When building with Maven 2
> it works correctly.
> I tried to isolate the problem with a simpler scenario, but could only
> reproduce using the *org.apache.xmlgraphics:fop:jar:1.0* dependency.
> Maven 3 dependency output snippet:
> {noformat}
> [DEBUG] test:a:jar:1
> [DEBUG]test:a-deps:pom:1:provided
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:compile
> [DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
> [DEBUG] xml-apis:xml-apis-ext:jar:1.3.04:compile
> [DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:provided
> [DEBUG]org.apache.xmlgraphics:batik-js:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:compile
> [DEBUG] xalan:xalan:jar:2.6.0:compile
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-transcoder:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-svggen:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-extension:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:compile
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:provided
> {noformat}
> Maven 2 dependency output:
> {noformat}
> [DEBUG] test:a:jar:1 (selected for null)
> [DEBUG] test:a-deps:pom:1:provided (selected for provided)
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided (selected for
> provided)
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> (selected for provided)
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided (selected for
> provided)
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided
> (removed - causes a cycle in the graph)
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:provided (selected
>
[jira] Commented: (MCOMPILER-143) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MCOMPILER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252934#action_252934
]
Kari J. Niemi commented on MCOMPILER-143:
-
Now that I've studied maven architecture a bit more, I suppose this is not a
problem in the maven-compiler-plugin because the "classPathElements" is fed to
it via the plug-in framework.
-I could not yet find out which maven/other component is setting up the wrong
"classPathElements"
-Anyone have any idea, where to address this fault?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MCOMPILER-143
> URL: http://jira.codehaus.org/browse/MCOMPILER-143
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-143) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MCOMPILER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252937#action_252937
]
Kari J. Niemi commented on MCOMPILER-143:
-
Apparently this kind of issues have been handled in Maven 2 & 3: "Plugins and
Lifecycle". Could somebody with enough rights move this issue there?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MCOMPILER-143
> URL: http://jira.codehaus.org/browse/MCOMPILER-143
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253808#action_253808
]
Kari J. Niemi commented on MNG-4996:
Thanks Kristian. I tried both, the fixed version and also the
-Dmaven.artifact.threads=1. I still get the same error.
I wonder which part of maven(or some plugin) is setting up&handing out the
classpath?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253817#action_253817
]
Kari J. Niemi commented on MNG-4996:
I tried them both separately but not together. Is that relevant?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253946#action_253946
]
Kari J. Niemi commented on MNG-4996:
Uhhh...now this got to the level of my incompetence. Checked out succesfully,
but my internal repository does not contain all the artifacts needed for
building and I'm not supposed(capable? don't know how...) to use external
repositories(maven central)...
(Yes, you figured it, it's unfortunately closed source.)
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4980) Shared local repository
[ http://jira.codehaus.org/browse/MNG-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254775#action_254775 ] Kari J. Niemi commented on MNG-4980: I'm thumbs up with this as well. A recommended practice for CI build servers and multiuser environments is to have local repository per CI build or per user. This effectively makes it impossible for the OS to use file cacheing efficiently as there are 10s to hundreds of copies of the same artifacts. I have no benchmarks though. Of course, for build reproducability(troublehooting it is good that there are separate lccal repository structures for the different builds/servers. But wouldn't there be any OS cacheing friendlier way for storing the maven artifacts that are supposedly shared by many users/CI builds? > Shared local repository > --- > > Key: MNG-4980 > URL: http://jira.codehaus.org/browse/MNG-4980 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 3.1 >Reporter: Markus KARG >Priority: Minor > > Execution speed of mvn is directly dependent to the fact that there are lots > of artifacts to get resolved via internet (or even slow LANs). To reduce the > impact of the internet's delay, one can use artifact managers like Nexus > serving as a cache to all LAN users. To reduce the impact of the LAN's delay, > mvn uses a local repository serving as a cache to all local users. > But that local cache (.m2/repository) is private to the user. While it makes > sense that there is a private repository for every user (e. g. so one user is > not able to install manually into other user's repository, or so one user > cannot see really private things of another user), it makes no sense that > there is no shared cache for all users. > My proposal would be that mvn splits the local repository into two parts. The > first part is a cache used by all users of that machine (which could be > hundreds in case of terminal servers or university class room machines) (on > Windows best located at %PROGRAMDATA%\.m2\repository). It gets filled solely > by downloading from a private or public repository, but one cannot install > into that to keep privacy and stability. The second part is the existing > repository (%USERPROFILE%\.m2\repository) and it gets filled only by manual > installing using mvn install. > Thanks to this splitting, chances are good that shared machines will have > latest dependencies stored locally already, reducing LAN delay. Builds run > faster then. Also, the user's own local repository is much cleaner then, > showing only his own manually installed projects, but not cached dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
