[
https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115255#comment-16115255
]
ASF GitHub Bot commented on SUREFIRE-1396:
------------------------------------------
Github user jon-bell commented on the issue:
https://github.com/apache/maven-surefire/pull/161
@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).
> Provider class path is incorrect for custom provider in Failsafe
> ----------------------------------------------------------------
>
> Key: SUREFIRE-1396
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1396
> Project: Maven Surefire
> Issue Type: Bug
> Reporter: Jonathan 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.
> It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the
> Surefire plugin hardcoded, which isn't correct when it's actually Failsafe).
> I've got a patched fork of master on GitHub
> (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2)
> that fixes it and an integration test that demonstrates the flaw. I am not
> 100% sure on the formatting of the integration test (i.e., I am opening a
> JIRA ticket so that I suppose I can name it under the JIRA issue? How should
> I specify the current version of surefire in the integration test package?) -
> if the fix is welcome against master I'd be happy to open a PR on GitHub. I
> am also happy to merge against a different branch if it's more helpful.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
