+1 Tibor got a good point noticing that we use scope provided for some junit artifacts which can impact the way the classpath is built.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 5 sept. 2018 à 10:31, Christian Stein <sormu...@gmail.com> a écrit : > On Wed, Sep 5, 2018 at 10:22 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > From what I saw in the code the surefire provider artifact is resolved to > > ... > > > So, specifying that artifact in your setup (explicit or implicit) will lead > to the correct version > to be loaded. See the integration tests in Surefire, JUnit 5 sample > projects, Spring Boot, et al. > > ... therefore it ignores the project overrides without my patch. > > > Which is an improvement! And Surefire needs such a logic. I did something > similar here: > > https://github.com/sormuras/junit-platform-maven-plugin/blob/05b7e3ae521ccb7f71d00ccd532523a99a9b6dfc/src/main/java/de/sormuras/junit/platform/maven/plugin/Resolver.java#L87-L116 > > So, my plan is: > > 1. Check meecrowave configuration if it is possible to get it running with > 2.22.0 and 5.3 > 2. Improve Surefire >
