I don't see releasing Surefire 3.0 as fixing this problem. Users having an upgrade policy in place would still not be able to upgrade to 3.0 anyway. We are talking about a backward incompatible change in a maintenance release of the Surefire plugin. As much as I welcome 3.0 to be GA, that won't change anything to what we're discussing here IMO.
Cheers, S. On Tue, May 5, 2020 at 8:07 AM Enrico Olivelli <eolive...@gmail.com> wrote: > I would go with option 'release surefire 3.0.0' > > > Enrico > > Il Mar 5 Mag 2020, 07:59 Romain Manni-Bucau <rmannibu...@gmail.com> ha > scritto: > > > Hmm, this particular one is quite hard cause (from my window which is not > > 100% of users indeed) I see more users willing 1.6 (actually I should > > phrase it "upgrade to last junit5 when upgrading surefire") than other > > cases. > > Concretely, older versions will not upgrade surefire generally. > > I think we are "just" in a case where you encounter a bug with a release > > policy preventing to go to 3.x and this is why you want this particular > > case. > > Anyone has another view of users? (point being: if we downgrade and break > > all users not using spring boot parent we are exactly at the same point > so > > let's try to avoid that). > > > > So question for me is: > > > > 1. Do we stick to that strategy and if so which version do we pick for > > 2.22.x and do we freeze this version? > > 1.a. junit 5.6 > > 1.b. junit 5.3 > > 1.c junit 5.5 (aka spring-boot current one AFAIK) > > 2. Do we backport 3.x strategy (or an enhanced flavor we do in 3.x and > > 2.22.x)? > > 3. Do we (just) document junit-platform* must be explicitly set in > project > > dependencies for 2.22? (side note there: doc/website of 2.22 seems no > more > > directly accessible online, is it intended since here the config is > > different?) > > 4. Do we just do a 3.0.0? (M4 is proven quite stable now so we could > > mitigate coming changes which are not testing provider related I think) > > > > I'd be for 1 (whatever version works) or 3 since it is the least > investment > > very short term and enables to go with 4 as soon as ready. > > > > Hope it makes sense. > > > > 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 lun. 4 mai 2020 à 20:42, Stephane Nicoll <stephane.nic...@gmail.com> > a > > écrit : > > > > > OK. With that in mind, I think the surefire plugin shouldn't require a > > > newer version of JUnit in a maintenance release that way. I understand > > it's > > > fixed and can lead to problem anyway but there will be less problems if > > you > > > rely on an older version and backward compatiblity if a newer version > is > > > around. I think we need to weigh what that change brings vs. the impact > > on > > > existing users upgrading to 2.22.3 > > > > > > On Mon, May 4, 2020 at 7:36 PM Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > > wrote: > > > > > > > Yes but with transitive game it is not well positionned in the > > classpath > > > > (once again not saying it is "right", just the way it was done > > > originally) > > > > and surefire provider dependencies win so it must be redefined to be > > used > > > > in 2.x. > > > > > > > > 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 lun. 4 mai 2020 à 18:52, Christian Stein <sormu...@gmail.com> a > > > écrit : > > > > > > > > > On Mon, May 4, 2020 at 6:45 PM Romain Manni-Bucau < > > > rmannibu...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > Le lun. 4 mai 2020 à 18:30, Stephane Nicoll < > > > stephane.nic...@gmail.com > > > > > > > > > > a > > > > > > écrit : > > > > > > > > > > > > ... > > > > > > > > > > > OK. Why is our build failing with that error if we're importing > the > > > > JUnit > > > > > > > 5.5.2 bom and it does not fail if we're importing the JUnit > 5.6.2 > > > > bom? > > > > > > Our > > > > > > > test dependencies have "junit-jupiter" in test scope which > brings > > > the > > > > > > > engine. > > > > > > > > > > > > > > That looks like Surefire is using the user version to me. > Anyway, > > > if > > > > it > > > > > > > wasn't we wouldn't have the error above, wouldn't we? > > > > > > > > > > > > > > > > > > > AFAIK you don't import junit-platform-launcher in 1.5.2 so it > > fails. > > > > > > So surefire uses user version but misses one dep which takes in > its > > > own > > > > > > pom. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://repo.maven.apache.org/maven2/org/junit/junit-bom/5.5.2/junit-bom-5.5.2.pom > > > > > > > > > > > > > > > contains > > > > > > > > > > <dependency> > > > > > <groupId>org.junit.platform</groupId> > > > > > <artifactId>junit-platform-launcher</artifactId> > > > > > <version>1.5.2</version> > > > > > </dependency> > > > > > > > > > > > > > > >
