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? 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] > > > > >
