[MNG-7220] [REGRESSION] test-classpath incorrectly resolved

[jira-importer]

Robert Scholte opened MNG-7220 and commented

The integrationtest of MJAVADOC-259 succeeds with Maven 3.8.1, but fails with 3.8.2.

Git bisect identifies 76d5f0d as the first bad commit

---

Affects: 3.8.2

Attachments:

• 381.log (313.11 kB)
• 382.log (322.69 kB)

Issue Links:

• MNG-7251 Fix threadLocalArtifactsHolder leaking into cloned project
  ("is fixed by")
• MNG-6843 Parallel build fails due to missing JAR artifacts in compilePath
  ("is caused by")

Remote Links:

• GitHub Pull Request #527
  
• GitHub Pull Request #535
  

Backported to: 4.0.0-alpha-2, 3.8.3

0 votes, 6 watchers

[jira-importer]

Robert Scholte commented

I hope Falko Modler can help investigate this one. My first suspect would be the @Execute( phase = LifecyclePhase.GENERATE_TEST_SOURCES ) on the Mojo class.

[jira-importer]

Falko Modler commented

Standard Maven plugins are not tested with a new Maven release before it's released? That's unfortunate, given all the test coverage that's in those plugins...

I'm not familiar with the internals of @Execute. Does it spawn a new Thread? Can you point me to the implementation, Robert Scholte? Thanks!

[jira-importer]

Michael Osipov commented

Robert started working on this, but the setups are getting more and more complex as you can see. Another unfortunately thing is that people don't test during voting phase. I have the vote open for at least one week. If we can't sort this out, I will need to revert until we can solve this. :-(

[jira-importer]

Falko Modler commented

I understand the urgency, that's why I'll try to help. I was actually about to integrate Maven 3.8.2 in Quarkus and I will pause that now, until we better understand the impact of this.

[jira-importer]

Michael Osipov commented

I know and I am grateful for your help. Take your time.

[jira-importer]

Falko Modler commented

I think I got it!
The problem is how MavenProject is cloned for those forked lifecycles: clone() simply copies threadLocalArtifactsHolder over to the clone and so both instances share the same ThreadLocal, which is wrong and leads to artifacts getting lost in the fork (in this specific case, different scenarios might yield other stange results).
I succeeded in fixing this problem locally by swapping the copied threadLocalArtifactsHolder with a new one and doing an explicit deep copy of ArtifactsHolder.

I'll have to think about on how to clean this up. I'd rather prevent the TL from being "copied" in the firstplace (instead of swapping it "manually").

[jira-importer]

Falko Modler commented

FTR, this is the trace leading to the clone:

at org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1229)
at org.apache.maven.project.MavenProject.clone(MavenProject.java:1192)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:336)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:173)
at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java:273)
at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:154)
at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:235)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:972)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

[jira-importer]

Michael Osipov commented

This is awesome news...please keep us updated!

[jira-importer]

Falko Modler commented

Michael Osipov Do I have to create a PR targeting master first? Or can I create the 3.8.x one first?

[jira-importer]

Michael Osipov commented

Lets try on 3.8.x first, then merge and then to master.

[jira-importer]

Falko Modler commented

PR for 3.8.x: #527

[jira-importer]

Stefan Seifert commented

the ticket WTOOL-78 described a problem with building javadoc as part of a maven site generation that fails due to the problem described in this ticket:

• build fails in when generating the maven site during the javadoc step, which is unable to find a couple of dependencies which are defined correctly (they are defined as "provided" in the <dependency> section of one of the parent POMs)
• the build does not fail when "javadoc:javadoc" is executed directly, only as part of the "site" goal
• everything runs fine with Maven 3.8.1 or 3.6.3

i can confirm that the problem is fixed with #527

[jira-importer]

Michael Osipov commented

I can confirm that this issue is fixed by the provided PR and the issue can be observed on Maven master. Falko Modler, can you provide a PR for master as well?

[jira-importer]

Falko Modler commented

Michael Osipov:

Falko Modler, can you provide a PR for master as well?
Done: #535

[jira-importer]

Michael Osipov commented

Thanks, will try apply in the next couple of days...