You may already override the JUnit Platform and Engine versions by supplying plugin dependency definitions. See

https://github.com/junit-team/junit5-samples/blob/a516d38439dec7be42488a5fd608f99af1d3c0f2/junit5-jupiter-starter-maven/pom.xml#L18-L48

@sormuras: this doesnt work - you can check on meecrowave (junit module) project because classpath ignores both peoject and plugin dependencies so you end up using plugin build dependencies for part of the stack.

@sormuras
The POM in platform provider contains junit-platform-launcher.
I think that Romain's problem is with existence of this dependency in the provider classpath. I think it should have <scope>provided</scope>. Then the dependency would not appear in the provider's classpath and the user has to add.
Another way would be more complicated for us but more user friendly for user. Discover the junit-platform-launcher and it transitive dependencies in dependencies and the algorithm would be complicated because it has to resolve them. Basically it has to use the launcher and engine if specified; otherwise use the one with version 1.2.0. But this would lead to uncertain behavior because the users would not clearly understand when to use it and when not in certain versions.

@rmannibucau
Why on why people still use plugin dependencies since the plugin has its own ClassLoader and has nothing to do with project dependencies.

@Tibor17 cause you don't want to put the dependency in the project at all since it is about the platform and surefire integration, not the project itself. Even the engine shouldn't be in the project dependencies, only the API. Also this was the way junit5 surefire plugin was done before the donation ;).

@sormuras
Is there a guarantee that the junit-platform-launcher is backwards compatible across versions?
If it is and will be guaranteed then the trick with engine would help the users in Surefire documentation. Maybe it would be a good way to provide a link to https://github.com/junit-team/junit5-samples as well.

Solved for meecrowave via apache/openwebbeans-meecrowave#11

At least two things are still open:

1. Improve the documentation to address this setup
2. Evaluate whether this PR improves Surefire's dependency handling - if yes, apply it, if not, close it.

@mureinik reported a side-effect with reuseForks=false over at junit-team/junit5#1579 -- does this PR also fixes this issue?

@rmannibucau
I would like to reproduce this issue. Can you write a small project in your GitHub repository? Thx

@rmannibucau
@sormuras
I will try to test @rmannibucau's test project and scope=provided dependency junit-jupiter-engine in our provider surefire-junit-platform. I think personally that the provider should be only compiled with a help of 3rd party dependencies but the runtime classpath should not use these dependencies because they are subject of declaring by user in POM. This fix would be easy and since every user has to use either junit-jupiter-engine or junit-vintage-engine the transitive dependency junit-platform-launcher appears in both. Is there any engine where the junit-platform-launcher does not exist?

@rmannibucau
@sormuras
According to this picture [1] it is obvious that the junit-platform-launcher is always available in any engine. When looking into Surefire's providers like TestNG provider or JUnit4 provider, one can see that the 3rd party dependencies always have scope provided. So I think we should continue in this tradition and I hope the scope would fix our problem.
[1]: https://dzone.com/storage/temp/7348826-dzone1.gif

Somebody wants to write a parameterized IT with versions 5.2.0, 5.3.0, 5.3.1?
It is worth to utilize @sormuras' code asserting the classpath 95fa1d8

Just to chime in as we are as well hit by this exact problem in https://github.com/flowable/flowable-engine/tree/master/modules/flowable-cxf. I've tried doing the exact thing that @sormuras did with apache/openwebbeans-meecrowave#11, but it didn't work.

I have not tried it but I think that if one puts reuseForks=true and forkCount=1 (we have forkMode=always which according to the surefire documentation leads to the reuseForks and forkCount that I mentioned) in https://github.com/junit-team/junit5-samples/blob/master/junit5-migration-maven/pom.xml the problem would be shown.

@rmannibucau
Thx for contributing. We have fixed this issue. Please close this PR.