Hi Sandra,
there is a surefire-integration plugin to junit-platform-maven-plugin for
example to mitigate the migration (was literally migrating surefire config
to the new plugin).
What I think we should rely on maven 4 momentum to do:
* Ensure surefire codebase is literally an "exec" or ToolProvider.exec of
launcher and be it ("one class mojo" style)
* Surefire configuration is not overlapping with underlying engine
configuration to promote the underlying engine defaults instead of
promoting our defaults (it is always weird to name XTest a spock test which
should be named XSpec for ex and this 100% comes from the fact surefire
doesn't respect its engine but hardcodes its default). In other words we
have an abstraction of engine an unify the plugin and command/phase but we
do not break end user habits
What can be challenging in terms of configuration mainly relates to manual
command habits -Dtest=xxxx -Dmaven.surefire.debug but there again I guess
we can have a surefire-integration-extension we inject in the build if
needed and which auto configures the plugin.
This way native maven 4 users will just never use it and maven 3 migrating
users will add the extension and keep their build.
The key point is the momentum we have now, we can break now and not for the
next 10 years for exactly the reasons you mention and surefire is a pain
since 10+ years so if we can drop 100% of its abstractions it is a huge win.
Indeed I'm ok to do it in phases, and adopting junit engine/platform now is
a huge win for maven 3 baseline but maven 4 enables to go further and it
was all the thread goal, to identify if we go or not.
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 jeu. 2 oct. 2025 à 12:52, Sergey Chernov <[email protected]> a
écrit :
> +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]
> >
> >
>
