Re: issue with junit 5 integration

2018-09-05 Thread Christian Stein
On Wed, Sep 5, 2018 at 6:49 PM Tibor Digana wrote: > >> Yes but the platform and engine are transitive, right? > Yes. We can grab the classpath from the forked jvm via Jconsole and we > should see these artifacts. > > @Christian > what happens when you just add new Engine with another version to

Re: issue with junit 5 integration

2018-09-05 Thread Tibor Digana
>> Yes but the platform and engine are transitive, right? Yes. We can grab the classpath from the forked jvm via Jconsole and we should see these artifacts. @Christian what happens when you just add new Engine with another version to the POM's dependencies or plugin's dependencies. The old

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
Le mer. 5 sept. 2018 18:20, Tibor Digana a écrit : > Romain, that link in Resolver means that our Provider has transitive > dependencies. This Surefire's Platform Provider + it's dependencies. Not > the JUnit5's provider. > Yes but the platform and engine are transitive, right? Adding engine

Re: issue with junit 5 integration

2018-09-05 Thread Tibor Digana
(Sorry, I had to re-send my email from apache.org) Romain, that link in Resolver means that our Provider has transitive dependencies. This Surefire's Platform Provider + it's dependencies. Not the JUnit5's provider. Adding engine with another version makes sense to me in current situation. It's

Re: issue with junit 5 integration

2018-09-05 Thread Tibor Digana
Romain, that link in Resolver means that our Provider has transitive dependencies. This Surefire's Platform Provider + it's dependencies. Not the JUnit5's provider. Adding engine with another version makes sense to me in current situation. It's similar to what we are doing when we add

Re: issue with junit 5 integration

2018-09-05 Thread Christian Stein
So. Initial results are in. Setting only: 3.0 ...leads to the exception Romain reported. Version 1.2.0 of the Platform is resolved. Sorting out the test compile- and runtime dependencies fixes the issue: See https://github.com/apache/meecrowave/pull/11 for details. Now, making Surefire

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
+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 | Blog | Old Blog |

Re: issue with junit 5 integration

2018-09-05 Thread Christian Stein
On Wed, Sep 5, 2018 at 10:22 AM Romain Manni-Bucau 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,

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
>From what I saw in the code the surefire provider artifact is resolved to build the classpath ignoring the project configuration (it is just an artifact resolution) and therefore it ignores the project overrides without my patch. Romain Manni-Bucau @rmannibucau

Re: issue with junit 5 integration

2018-09-05 Thread Stephane Nicoll
I am more interested to understand what is particular in that project that exhibits an issue we don't seem to be facing. That thread is phrased in such a way that it is a general problem and I'd like a confirmation of that as it may impact Spring Boot (amongst other things) Thanks, S. On Wed,

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
@Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk and change the version in the junit pom ( https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml), it will fail then Romain Manni-Bucau @rmannibucau | Blog

Re: issue with junit 5 integration

2018-09-05 Thread Christian Stein
On Wed, Sep 5, 2018 at 10:07 AM Stephane Nicoll wrote: > How do I reproduce this problem concretely? Having to specify a dependency > in surefire is not an option for us as we want the JUnit5 provider to be > detected automatically. > > I've upgraded a Spring Boot project to use 5.3.0 and I

Re: issue with junit 5 integration

2018-09-05 Thread Stephane Nicoll
How do I reproduce this problem concretely? Having to specify a dependency in surefire is not an option for us as we want the JUnit5 provider to be detected automatically. I've upgraded a Spring Boot project to use 5.3.0 and I don't see any problem. Thanks, S. On Tue, Sep 4, 2018 at 10:46 PM

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
Me too but https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142 only handles a single artifact whereas junit5 relies on N > 1 artifacts for its stack. Romain

Re: issue with junit 5 integration

2018-09-05 Thread Dan Tran
" surefire provider forces 1.2.0" this is not good :-) i thought surefire auto detect first one available in classpath On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau wrote: > jupiter ;) > > junit 5 is not jupiter but platform+ engine*s* so it must detect the full > stack and not just the

Re: issue with junit 5 integration

2018-09-05 Thread Romain Manni-Bucau
jupiter ;) junit 5 is not jupiter but platform+ engine*s* so it must detect the full stack and not just the default. A first step can be to detect platform+jupiter+engine but I guess we will get spock, cucumber etc engine quickly so being generic can be worth it. In my case I have vintage-engine

Re: issue with junit 5 integration

2018-09-04 Thread Dan Tran
Odd, I am under impression surefire auto detect junit-jupiter-engine at runtime am I missing something? -D On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau wrote: > It does _NOT_ work and as mentionned you can test on meecrowave trying to > upgrade the version in junit module. > > The

Re: issue with junit 5 integration

2018-09-04 Thread Romain Manni-Bucau
It does _NOT_ work and as mentionned you can test on meecrowave trying to upgrade the version in junit module. The test classpath build ignores project and plugin dependencies. It faked working until 5.3.0-RC1 cause no breakage was visible. When testing, dont forget to use jupiter, vintage

Re: issue with junit 5 integration

2018-09-04 Thread Olivier Lamy
Ok perso I don't mind (it just need to be documented) But the issue is: users are used to simply upgrade their junit dependency. On Wed, 5 Sep 2018 at 07:37, Christian Stein wrote: > No, it works with Surefire 2.22.0 and JUnit 5.3. > > Just add (or move) the test-runtime dependencies to the

Re: issue with junit 5 integration

2018-09-04 Thread Christian Stein
No, it works with Surefire 2.22.0 and JUnit 5.3. Just add (or move) the test-runtime dependencies to the Surefire plugin element: maven-surefire-plugin 2.22.0 org.junit.jupiter

Re: issue with junit 5 integration

2018-09-04 Thread Olivier Lamy
Hi very embarrassing issue which probably worth a quick release! Can you create a jira? As junit 5.3.0 has just been released, I might be happy to cut 2.22.1 very quickly with only this fix. others wdyt? On Wed, 5 Sep 2018 at 06:46, Romain Manni-Bucau wrote: > Hi guys, > > Jira seems down so