SUREFIRE-1396: Provider class path is incorrect for custom provider in Failsafe

[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.

[Tibor17]

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]

I did a mvn verify from the top level. I will do a mvn install -P run-its now.

[Tibor17]

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]

Sorry about that - hadn't noticed that it wasn't specified. Added it to both the provider and the test project.

[Tibor17]

Why?
See the build.log in target and you will see project version and all necessary dependencies hidden in the fork transitive deps.

[Tibor17]

This plugin is again in parent pom. Not necessary here.

[jon-bell]

Thanks. I will clean this up. FYI, the entire pom.xml is copied from the SUREFIRE-141 IT pom.xml.

[Tibor17]

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" );.

[jon-bell]

Thanks - I made the fixes you suggested above, and confirmed that the build passed on mvn clean install -P run-its

[Tibor17]

@jon-bell
Please squash your commits into one single commit and override your branch. Name the final commit
[SUREFIRE-1396] Provider class path is incorrect for custom provider in Failsafe

[jon-bell]

Done

[Tibor17]

@jon-bell
I will investigate this issue:
Could not find artifact org.apache.maven.surefire:it-parent:pom:1.0 in central (https://repo.maven.apache.org/maven2)

[jon-bell]

@Tibor17 It seems like it had worked for me because I had previously executed a mvn install - I see on a clean maven repo the problem.

It looks like the SurefireLauncher does not unpack/install the parent pom into the it-repo, and hence, the forked maven process can't find the parent pom (once it's installed). I am hesitant to poke at this further, because I suspect a fix might involve some changes to SurefireLauncher to coerce it to install the parent pom into the it-repo as well. This seems to not be a problem for any test packages, but is for a provider (which gets the forked Maven classloader instead of the test classloader). Given that the only other provider in the repo for integration tests does not reference the parent pom, I assume that this is a problem that someone came upon before and sidestepped.

I've removed the parent reference that you had suggested above. But, we are properly picking up surefire.version from the maven system property. On a clean maven repo the mvn clean install -P run-its completed with this version (now again squashed). I agree that referencing the parent pom is a cleaner solution, but I'm not sure if you/we want to go down the road of patching the integration test harness to support that (for what amounted to a ~3 line patch).

[jon-bell]

@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 mvn clean install -P run-its on a clean m2 repo. It does not reference the parent pom, but also does not define the surefire.version property.

Thanks
Jonathan

[jon-bell]

@Tibor17 Is there anything else I can do to help get this merged?

[Tibor17]

@jon-bell
Ok, now your IT passed. I will run whole test set now.

[asfbot]

Tibor Digana on dev@maven.apache.org replies:
Check your branch if it is up to date with master.

[jon-bell]

@Tibor17 I have rebased master on top of my branch, it is again up to date.

[Tibor17]

@jon-bell
Thx for contributing.