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]
