SUREFIRE-1396: Provider class path is incorrect for custom provider in Failsafe #161
Conversation
<name>Test provider</name> | ||
|
||
<properties> | ||
<surefire.version>2.21-SNAPSHOT</surefire.version> |
Tibor17
Jul 31, 2017
Contributor
Pls do not use this property. It comes from parent pom.
Did you run the build like this mvn install -P run-its
?
Pls do not use this property. It comes from parent pom.
Did you run the build like this mvn install -P run-its
?
jon-bell
Jul 31, 2017
Author
Contributor
I did a mvn verify
from the top level. I will do a mvn install -P run-its
now.
I did a mvn verify
from the top level. I will do a mvn install -P run-its
now.
Tibor17
Jul 31, 2017
Contributor
You should specify parent pom
<parent>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>it-parent</artifactId>
<version>1.0</version>
<relativePath>../pom.xml</relativePath>
</parent>
You should specify parent pom
<parent>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>it-parent</artifactId>
<version>1.0</version>
<relativePath>../pom.xml</relativePath>
</parent>
jon-bell
Aug 1, 2017
Author
Contributor
Sorry about that - hadn't noticed that it wasn't specified. Added it to both the provider and the test project.
Sorry about that - hadn't noticed that it wasn't specified. Added it to both the provider and the test project.
<dependencies> | ||
<dependency> | ||
<groupId>org.apache.maven.surefire</groupId> | ||
<artifactId>surefire-api</artifactId> |
Tibor17
Jul 31, 2017
Contributor
Why?
See the build.log
in target and you will see project version and all necessary dependencies hidden in the fork transitive deps.
Why?
See the build.log
in target and you will see project version and all necessary dependencies hidden in the fork transitive deps.
<plugins> | ||
<plugin> | ||
<groupId>org.apache.maven.plugins</groupId> | ||
<artifactId>maven-compiler-plugin</artifactId> |
Tibor17
Jul 31, 2017
Contributor
This plugin is again in parent pom. Not necessary here.
This plugin is again in parent pom. Not necessary here.
jon-bell
Jul 31, 2017
Author
Contributor
Thanks. I will clean this up. FYI, the entire pom.xml is copied from the SUREFIRE-141 IT pom.xml.
Thanks. I will clean this up. FYI, the entire pom.xml is copied from the SUREFIRE-141 IT pom.xml.
Artifact plugin = pluginArtifactMap.get( "org.apache.maven.plugins:maven-surefire-plugin" ); | ||
Class<?> c = AbstractSurefireMojo.this.getClass(); | ||
Artifact plugin; | ||
if ( c.getName().equals( "org.apache.maven.plugin.failsafe.IntegrationTestMojo" ) ) |
Tibor17
Jul 31, 2017
Contributor
I guess this is in method getProviderClasspath()
Please split the method in two. First it would call protected abstract Artifact getMojoArtifact()
and then the original statement return dependencyResolver.addProviderToClasspath( pluginArtifactMap, plugin );
where plugin
is Artifact
. Then force both subclasse to implement getMojoArtifact
which means surefire mojo will implement it as follows:
final Map<String, Artifact> pluginArtifactMap = getPluginArtifactMap(); Artifact plugin = pluginArtifactMap.get( "org.apache.maven.plugins:maven-surefire-plugin" );
.
I guess this is in method getProviderClasspath()
Please split the method in two. First it would call protected abstract Artifact getMojoArtifact()
and then the original statement return dependencyResolver.addProviderToClasspath( pluginArtifactMap, plugin );
where plugin
is Artifact
. Then force both subclasse to implement getMojoArtifact
which means surefire mojo will implement it as follows:
final Map<String, Artifact> pluginArtifactMap = getPluginArtifactMap(); Artifact plugin = pluginArtifactMap.get( "org.apache.maven.plugins:maven-surefire-plugin" );
.
Thanks - I made the fixes you suggested above, and confirmed that the build passed on |
@jon-bell |
Done |
@jon-bell |
@Tibor17 It seems like it had worked for me because I had previously executed a It looks like the I've removed the parent reference that you had suggested above. But, we are properly picking up |
@Tibor17 Let me know if there is anything else I can do on this. My new patch (rebased into a single commit) works fine on a Thanks |
@Tibor17 Is there anything else I can do to help get this merged? |
@jon-bell |
Tibor Digana on dev@maven.apache.org replies: |
@Tibor17 I have rebased master on top of my branch, it is again up to date. |
@jon-bell |
Hi,
When using a custom Surefire provider with Surefire (not Failsafe), the "provider classpath" contains only the provider and surefire-api. However, when using a custom provider with Failsafe, the provider class path ends up including a lot more... it seems like perhaps all plugins that are loaded? This has caused some mayhem for me when using a custom provider in projects that use a specific version of SLF4J... because then failsafe forces 1.5.6 to be loaded (from this process of incorrectly finding the custom provider), causing a crash.
This PR contains an integration test case showing the bug and a patch to solve it.