You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Andy Wilkinson (JIRA)" <ji...@apache.org> on 2019/07/15 10:14:00 UTC

[jira] [Created] (SUREFIRE-1679) Caching of provider classpath with module-specific changes may break testing bootstrapping in subsequent modules

Andy Wilkinson created SUREFIRE-1679:
----------------------------------------

             Summary: Caching of provider classpath with module-specific changes may break testing bootstrapping in subsequent modules
                 Key: SUREFIRE-1679
                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1679
             Project: Maven Surefire
          Issue Type: Bug
          Components: Maven Surefire Plugin
    Affects Versions: 3.0.0-M3, 2.22.2
            Reporter: Andy Wilkinson
         Attachments: surefire-pollution-problem.zip

I believe I've identified a bug in the caching that's performed by {{AbstractSurefireMojo}}. The problem that I am seeing is a failure to bootstrap Surefire:

 
{noformat}
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the forked process
[ERROR] java.lang.NoClassDefFoundError: org/junit/platform/launcher/core/LauncherFactory
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:657)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
[ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
 

This is in a module that uses Surefire and JUnit Jupiter 5.5:

 
{noformat}
<dependencies>
	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter</artifactId>
		<version>5.5.0</version>
		<scope>test</scope>
	</dependency>
</dependencies>
<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.22.2</version>
		</plugin>
	</plugins>
</build>
 {noformat}
 

Earlier in the reactor, another project is built which depends on {{junit-platform-launcher}}:

 
{noformat}
<dependencies>
	<dependency>
		<groupId>org.junit.platform</groupId>
		<artifactId>junit-platform-launcher</artifactId>
		<version>1.5.0</version>
	</dependency>
	<dependency>
		<groupId>org.junit.jupiter</groupId>
		<artifactId>junit-jupiter</artifactId>
		<version>5.5.0</version>
		<scope>test</scope>
	</dependency>
</dependencies>
<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.22.2</version>
		</plugin>
	</plugins>
</build>
{noformat}

For the problem to occur, both projects have to be built in the same reactor. Building of the module which depends on {{junit-platform-launcher}} is causing some pollution that results in the other module failing to build.

I believe I've tracked down the cause of this pollution to some caching that's performed by [AbstractSurefireMojo|https://github.com/apache/maven-surefire/blob/d96b95c4bda73c4a93506db38b9ca76b4d7b5743/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1750-L1756]:

{code:java}
testClasspathWrapper.avoidArtifactDuplicates( providerArtifacts );


Classpath providerClasspath = ClasspathCache.getCachedClassPath( providerName );
if ( providerClasspath == null )
{
    providerClasspath = ClasspathCache.setCachedClasspath( providerName, providerArtifacts );
}
{code}

The first line above removes the launcher artifact from {{providerArtifacts}}. These module-specific adjustments to the provider artifacts are then used to create the cached {{providerClasspath}}. When a subsequent module retrieves this cached classpath and uses it, the build fails as the launcher is missing.

I have attached a zip which contains a minimal build that should reproduce the problem. You should see it fail when you run the `verify` goal.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)