[
https://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283684#comment-283684
]
Frank Meilinger commented on MNG-4996:
--------------------------------------
I've tried to do further debugging with this problem (in my situation always
surefire testing classpath problems). Til now, it looks like a problem in the
maven itself when running massive parallel (-T 20) and not in the surefire
plugin. I found the following:
Scenario:
Building with -T 20 the build fails after some minutes always with a
ClassNotFound exception in the SurefirePlugin for classes which are defined as
dependency projects with scope test. Often, the junit classes itself could not
be found. The error occure randomly in different projects, but always while
surefire executes.
Analyze:
The Method org.apache.maven.project.MavenProject.setResolvedArtifacts(...) is
called from
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(...)
to set the actual resolved artifacts. The surefire plugin request this
artifacts (later) when executing with a call to
org.apache.maven.project.MavenProject.getArtifacts() to build the classpath for
executing the testing.
I put some printouts with timestamp to the maven (3.0.3) code and found, that
in case of this error, the setResolvedArtifacts() method in the MavenProject
object is called in the wrong order or at the wrong time. First the
setResolvedArtifacts() is called with all dependencies for the scopes
"compile,provided,runtime,system,test", some milliseconds later this setter is
called again for all dependencies for only the scopes "compile,runtime". After
that, the surefireplugin starts and calls the getArtifacts() method on the
MavenProject an gets the wrong (too short) list of artifacts and all test
dependencies are missing to build the surefire test classpath. This results in
the ClassNotFoundExecption of the surefire plugin.
Maybe the call to setResolvedArtifacts() is made too early before starting the
surefire test, because in between it's called again without the test
dependencies and before the surefire starts and calls the getArtifacts() method.
Looking a bit deeper I found, that the callstack for the setResolvedArtifacts()
is:
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:107)
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:259)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:202)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:155)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:147)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
I don't really understand the deeper parallel and synchronization mechanisms in
maven when using parallel builds, so I don't know what I could do for further
analyzing. Maybe someone could give me some information how to dig deeper in
this problem. I can reproduce the problem always for each run with -T 20 but it
occures often in different sub-projects but always with the described problem.
Frank
> Maven3 parallel build fails occasionally for classpath problems.
> ----------------------------------------------------------------
>
> Key: MNG-4996
> URL: https://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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
