+1 for all Sandra comments On Thu, Oct 2, 2025 at 11:30 AM Sandra Parsick <[email protected]> wrote:
> I'd like to add my user perspective: > > Introducing a new Maven plugin as a replacement for the Surefire plugin > will create work on the user side. The past teaches us that the > acceptance of such a change is not very high (see the discussion about > JUnit 3/4/5, maybe soon 6 will also join this discussion). Therefore, I > prefer the way that Olivier and Sebastian are preparing: Using the JUnit > Platform Runnner in the core of Surefire. We have a modernization with > not so much impact for the user. After the refactoring, IMHO we can go > further and think about how to adjust the Surefire plugin to have a > better integration with the Jupiter platform, clean up old defaults, etc. > > My 2ct to the JUnit 3 discussion: > > The last release of JUnit 3 was 2007. 18 years ago! I think that is > enough time for a migration :o). I know manual migration sucks. But > fortunately, nowadays we have tools like OpenRewrite [2] that can > automate the happy part and help automate the custom part [3]. Of > course, it depends on your customization how big the manual part will > stay. But hey, that is the known consequence of customizing. > To be honest, if you have no problem staying on JUnit 3 then you should > be okay to stay on an older Surefire plugin version that supports JUnit 3. > > Sandra > > [1] https://mvnrepository.com/artifact/junit/junit/3.8.1 > [2] > > https://docs.openrewrite.org/recipes/java/testing/junit5/migratejunittestcase > [3] https://docs.openrewrite.org/authoring-recipes > > Am 01.10.25 um 10:46 schrieb Romain Manni-Bucau: > > @Olivier junit5 platform (what we do use) comes with its configuration > but > > surefire overlaps a lot (~100%) with it and you can't use both together > > without having a half baked solution. While I do not think we'll ever > get a > > 100% coverage of the underlying engine (we'll likely keep default like > > *Tests/Test* enforced without preventing the defaults of JUnit for ex - > > current status is last part is broken), we should be able to respect all > > the rest - threading, discovery etc.... > > > > Indeed we can always make evolving surefire but what's the point since it > > is already superseeded? > > > > Romain Manni-Bucau > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > > Blog <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | LinkedIn > > <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > Le mer. 1 oct. 2025 à 01:10, Olivier Lamy <[email protected]> a écrit : > > > >> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau < > [email protected]> > >> wrote: > >>> > >>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <[email protected]> a > >>> écrit : > >>> > >>>> What I'm learning here is: > >>>> > >>>> - a project stuck on JUnit 3 stays on the last know version that > >> supports > >>>> it > >>>> - JUnit 4, 5, and 6 projects will benefit from the new plug-in and its > >> more > >>>> direct approach > >>>> - other test frameworks like TestNG are supported through JUnit 4+ > >>>> > >>>> Is that about right? > >>>> > >>> > >>> Junit 5 is a plateforme, if you have n engine for your test framework > you > >>> are converse. > >>> There was one for spock which is not supporter by surefire directly for > >> ex > >>> so it is more you are limited to what is supporter in the wild. > >>> > >>> Today surefire doesn't support junit5 for that reason for ex, its > >> filtering > >>> layer breaks partially that. > >>> > >> > >> Can you please give some details on "surefire doesn't support junit5"? > >> What do you mean here? > >> I'm reading this as "surefire cannot run Junit5 tests", which > >> obviously looks wrong. > >> > >>> > >>>> Thank you, > >>>> Gary > >>>> > >>>> > >>>> On Tue, Sep 30, 2025, 06:20 Romain Manni-Bucau <[email protected] > > > >>>> wrote: > >>>> > >>>>> Hi Olivier, > >>>>> > >>>>> Why I thrown this thread is because I think we can go futher and drop > >>>>> totally our asbtraction which has conflicts with the underlying > >> platform > >>>>> (discovery for ex) and just expose junit engine so we would use their > >>>> test > >>>>> discovery, their test filtering etc... > >>>>> This would make the configuration less awckward and the code way less > >>>>> abstracted so easier to maintain. > >>>>> > >>>>> Not saying your PR is not awesome (it is) but I think we can leverage > >>>> maven > >>>>> 4 to break a bit more and do our big housecleaning ;). > >>>>> > >>>>> No strong opinion on the plugin name but options should converge more > >>>> IMHO. > >>>>> > >>>>> Romain Manni-Bucau > >>>>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > >>>>> <https://dotnetbirdie.github.io/> | Blog < > >> https://rmannibucau.github.io/ > >>>>> > >>>>> | Old > >>>>> Blog <http://rmannibucau.wordpress.com> | Github > >>>>> <https://github.com/rmannibucau> | LinkedIn > >>>>> <https://www.linkedin.com/in/rmannibucau> | Book > >>>>> < > >>>>> > >>>> > >> > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > >>>>>> > >>>>> Javaccino founder (Java/.NET service - contact via linkedin) > >>>>> > >>>>> > >>>>> Le mar. 30 sept. 2025 à 11:12, Olivier Lamy <[email protected]> a > >> écrit : > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You should have a look at the work already started with this PR [1] > >>>>>> and previously discussed on Slack. I wanted to reach a certain > >> level > >>>>>> of stability before bringing it up on the mailing list. > >>>>>> The current approach leverages the JUnit 5 platform/engine to run > >> all > >>>>>> tests from JUnit 4.12 (via junit vintage which cannot run anything > >>>>>> before 4.12) onward up to JUnit 5 (6 shouldn't be a problem). > >> TestNG > >>>>>> support still needs to be added, but this shouldn't be an issue as > >>>>>> it's an external engine to add (similar to add vintage engine for > >>>>>> junit4) > >>>>>> > >>>>>> This change deliberately drops support for older JUnit versions > >> prior > >>>>>> to 4.12, which are no longer maintained even by the Junit team. > >>>>>> Users who still rely on those outdated/EOL versions can continue > >> using > >>>>>> the last Surefire release that supports them. > >>>>>> That code is effectively frozen, and no further updates are > >> expected > >>>>>> for legacy JUnit support. > >>>>>> > >>>>>> I believe this is a good direction because it preserves the same > >>>>>> plugin name and user-facing configuration, so the impact for users > >> is > >>>>>> minimal. > >>>>>> At the same time, it gives us much cleaner internals, reduces > >>>>>> duplication, removes a lot of dead code, and significantly cuts > >> down > >>>>>> on maintenance overhead with surefire. > >>>>>> > >>>>>> Regards > >>>>>> Olivier > >>>>>> > >>>>>> [1] https://github.com/apache/maven-surefire/pull/3179 > >>>>>> > >>>>>> > >>>>>> On Mon, 29 Sept 2025 at 17:18, Romain Manni-Bucau < > >>>> [email protected] > >>>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I'd like to start a thread about potentially dropping surefire > >>>> totally. > >>>>>>> The rational is that surefire (and failsafe) are mainly an > >>>> abstraction > >>>>>>> layer on top of main test providers. > >>>>>>> However, since JUnit5 the platform/engine is itself such an > >>>> abstraction > >>>>>>> layer and a runner. > >>>>>>> > >>>>>>> On another side, testng and junit4 are slowly getting abandonned > >> - > >>>> even > >>>>>> EE > >>>>>>> TCK started to move. > >>>>>>> > >>>>>>> In terms of additional features we do have the maven site > >>>> integratoin - > >>>>>> but > >>>>>>> I doubt it is much used outside and to be honest it can be > >> replaced > >>>>> with > >>>>>> a > >>>>>>> github/dev-factory link with more benefit these days. > >>>>>>> > >>>>>>> So overall I think we can converge by dropping surefire plugin in > >>>> favor > >>>>>> of > >>>>>>> a thin wrapper of junit5 console runner ([1]). > >>>>>>> > >>>>>>> Short terms I'm sure Christian could help us getting something > >> fast > >>>>> based > >>>>>>> on its implementation ([2] - including a small surefire > >> compatibility > >>>>>> mode) > >>>>>>> and long term it will reduce the maintenance cost we do have for > >> a > >>>> very > >>>>>>> poor gain in current world (site and remoting are no more key > >>>> features > >>>>>>> thanks the CI and doc evolution). > >>>>>>> > >>>>>>> Wdyt? Is maven 4 the mometum to do it? > >>>>>>> > >>>>>>> [1] > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > https://docs.junit.org/current/user-guide/#running-tests-console-launcher > >>>>>>> [2] https://github.com/sormuras/junit-platform-maven-plugin > >>>>>>> > >>>>>>> Romain Manni-Bucau > >>>>>>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > >>>>>>> <https://dotnetbirdie.github.io/> | Blog < > >>>>> https://rmannibucau.github.io/> > >>>>>> | Old > >>>>>>> Blog <http://rmannibucau.wordpress.com> | Github > >>>>>>> <https://github.com/rmannibucau> | LinkedIn > >>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book > >>>>>>> < > >>>>>> > >>>>> > >>>> > >> > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > >>>>>>> > >>>>>>> Javaccino founder (Java/.NET service - contact via linkedin) > >>>>>> > >>>>>> > >> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
