[MNG-5960] MojoExecutor overriding resolved artifacts of concurrently built MavenProject

[jira-importer]

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:

1. Clone this repository (git clone https://github.com/fvanderveen/maven-mojo-jojo.git)
2. Make sure the clone works single-threaded: mvn clean package. (This should succeed)
3. Clean the workspace (mvn clean)
4. 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

[jira-importer]

Michael Osipov commented

Does this one occur after MNG-6843 has been fixed?

[jira-importer]

Joep Weijers commented

This is still an issue. The example project maven-mojo-jojo still fails with:

$ mvn --version
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.9.3
Java version: 17.0.2, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-17.0.2.8-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" 

The Maven maven-non-destructive-mojo-executor Extension to prevent this issue stopped working with Maven 3.9.0, with the following error:

[main] [ERROR] Cannot invoke "org.codehaus.plexus.PlexusContainer.lookup(java.lang.Class)" because "this.container" is null