I would go to the original question. How important is the issue [1] for the user? If it is not important, then we can cut the release with one fix SUREFIRE-1679.
If it is important, which does not seem so yet, then we can backport smart resolver from the master. Technically possible! [1]: https://github.com/junit-team/junit5/issues/1909 On Tue, May 5, 2020 at 8:07 AM Enrico Olivelli <[email protected]> wrote: > > I would go with option 'release surefire 3.0.0' > > > Enrico > > Il Mar 5 Mag 2020, 07:59 Romain Manni-Bucau <[email protected]> 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 <[email protected]> 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 <[email protected] > > > > > > 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 <[email protected]> a > > > écrit : > > > > > > > > > On Mon, May 4, 2020 at 6:45 PM Romain Manni-Bucau < > > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > Le lun. 4 mai 2020 à 18:30, Stephane Nicoll < > > > [email protected] > > > > > > > > > > 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> > > > > > > > > > > > > > > -- Cheers Tibor --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
