Fabian van der Veen opened MNG-5960 and commented
I have found an issue with respect to the MojoExecutor in maven-core when building with multiple threads (e.g. -T1C).
I have created a small reproduction project here: https://github.com/fvanderveen/maven-mojo-jojo (in the readme is some more explanation of what I found to be the problem)
The reproduction, using the above code:
- Clone this repository (
git clone https://github.com/fvanderveen/maven-mojo-jojo.git)
- Make sure the clone works single-threaded:
mvn clean package. (This should succeed)
- Clean the workspace (
mvn clean)
- Attempt multi-threaded compilation with at least 2 threads (
mvn package -T2)
Boiled down, it seems like the MojoExecutor#ensureDependenciesAreResolved will cause an invocation to LifecycleDependencyResolver#resolveProjectDependencies for all projects in the current MavenSession if it's configuring a plugin that defines @Mojo(aggregator = true) and DependencyContext#isResolutionRequiredForAggregatedProjects return true.
This resolving may, if triggered at an unfortunate time, override resolved artifacts for projects that are being built concurrently.
In our case, a test-compile execution of the maven-compiler-plugin was just configured (setting the resolved artifacts to the test-scope artifacts), and right before its execution, the resolved artifacts got set back to the compile-scope artifacts due to a aggregator plugin being configured at around the same time.
Given the way the ensureDependenciesAreResolved is structured and what aggregator plugins should do/depend on, I think it would make more sense to only invoke LifecycleDependencyResolver#resolveProjectDependencies for the modules that are a (grand-)child of the current project.
I've created a maven extension (which can be placed in lib/ext) as a temporary workaround using said change; which may be found here if any one else is having the same problems: https://github.com/fvanderveen/maven-non-destructive-mojo-executor
Affects: 3.3.9, needing-scrub-3.4.0-fallout
Issue Links:
- MNG-5750 Sporadic failures in concurrent build
Backported to: waiting-for-feedback
1 votes, 9 watchers
Fabian van der Veen opened MNG-5960 and commented
I have found an issue with respect to the
MojoExecutorinmaven-corewhen building with multiple threads (e.g.-T1C).I have created a small reproduction project here: https://github.com/fvanderveen/maven-mojo-jojo (in the readme is some more explanation of what I found to be the problem)
The reproduction, using the above code:
git clone https://github.com/fvanderveen/maven-mojo-jojo.git)mvn clean package. (This should succeed)mvn clean)mvn package -T2)Boiled down, it seems like the
MojoExecutor#ensureDependenciesAreResolvedwill cause an invocation toLifecycleDependencyResolver#resolveProjectDependenciesfor all projects in the currentMavenSessionif it's configuring a plugin that defines@Mojo(aggregator = true)andDependencyContext#isResolutionRequiredForAggregatedProjectsreturn true.This resolving may, if triggered at an unfortunate time, override resolved artifacts for projects that are being built concurrently.
In our case, a
test-compileexecution of themaven-compiler-pluginwas just configured (setting the resolved artifacts to the test-scope artifacts), and right before its execution, the resolved artifacts got set back to the compile-scope artifacts due to a aggregator plugin being configured at around the same time.Given the way the
ensureDependenciesAreResolvedis structured and what aggregator plugins should do/depend on, I think it would make more sense to only invokeLifecycleDependencyResolver#resolveProjectDependenciesfor the modules that are a (grand-)child of the current project.I've created a maven extension (which can be placed in lib/ext) as a temporary workaround using said change; which may be found here if any one else is having the same problems: https://github.com/fvanderveen/maven-non-destructive-mojo-executor
Affects: 3.3.9, needing-scrub-3.4.0-fallout
Issue Links:
Backported to: waiting-for-feedback
1 votes, 9 watchers