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]
