You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2025/09/29 07:07:49 UTC
Maven 4 and surefire/failsafe drop?
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)
Re: Maven 4 and surefire/failsafe drop?
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
I remember that m-surefire-plugin got stuck internally with some old
version of Junit5
Sylwester
wt., 30 wrz 2025, 15:38 użytkownik Romain Manni-Bucau <rm...@gmail.com>
napisał:
> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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.
>
>
> > Thank you,
> > Gary
> >
> >
> > On Tue, Sep 30, 2025, 06:20 Romain Manni-Bucau <rm...@gmail.com>
> > 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 <ol...@apache.org> 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 <
> > rmannibucau@gmail.com
> > > >
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Mirko Friedenhagen <mf...@gmx.de.INVALID>.
+1 for everything Sandra stated.
Mit freundlichen Grüßen
Mirko Friedenhagen
—
Sent from my mobile
> Am 02.10.2025 um 11:21 schrieb Sandra Parsick <sa...@parsick.dev>:
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <se...@gmail.com> a
écrit :
> +1 for all Sandra comments
>
> On Thu, Oct 2, 2025 at 11:30 AM Sandra Parsick <sa...@parsick.dev> 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 <ol...@apache.org> a écrit :
> > >
> > >> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>>
> > >>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com>
> 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 <
> rmannibucau@gmail.com
> > >
> > >>>> 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 <ol...@apache.org> 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 <
> > >>>> rmannibucau@gmail.com
> > >>>>>>
> > >>>>>> 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: dev-unsubscribe@maven.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Sergey Chernov <se...@gmail.com>.
+1 for all Sandra comments
On Thu, Oct 2, 2025 at 11:30 AM Sandra Parsick <sa...@parsick.dev> 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 <ol...@apache.org> a écrit :
> >
> >> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>>
> >>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rmannibucau@gmail.com
> >
> >>>> 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 <ol...@apache.org> 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 <
> >>>> rmannibucau@gmail.com
> >>>>>>
> >>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
On Thu, 2 Oct 2025 at 21:38, Gary Gregory <ga...@gmail.com> wrote:
>
> On Thu, Oct 2, 2025 at 5:42 AM Sandra Parsick <sa...@parsick.dev> 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
>
> Yes, but the "happy part" isn't worth much in this specific case, IMO;
> it's the last 20% that consumes 80% of the time. For example, try
> converting Apache Commons VFS to JUnit 5...
>
no plan yet to drop Junit4 support.
Maybe such conversion could be done using AI or openrewrite
> Gary
>
> > 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 <ol...@apache.org> a écrit :
> > >
> > >> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <rm...@gmail.com>
> > >> wrote:
> > >>>
> > >>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rm...@gmail.com>
> > >>>> 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 <ol...@apache.org> 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 <
> > >>>> rmannibucau@gmail.com
> > >>>>>>
> > >>>>>> 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: dev-unsubscribe@maven.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Oct 2, 2025 at 5:42 AM Sandra Parsick <sa...@parsick.dev> 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
Yes, but the "happy part" isn't worth much in this specific case, IMO;
it's the last 20% that consumes 80% of the time. For example, try
converting Apache Commons VFS to JUnit 5...
Gary
> 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 <ol...@apache.org> a écrit :
> >
> >> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>>
> >>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rm...@gmail.com>
> >>>> 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 <ol...@apache.org> 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 <
> >>>> rmannibucau@gmail.com
> >>>>>>
> >>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Elliotte,
Think several points are, even if unrelated to this thread, wrong:
* Support: it is not more supporter so you can get surprises with recent
java versions or warnings at least
* JUnit3 is mainly about inheritance which is very limited and legacy since
Junit4 with rules and JUnit 5 goes the step further enabling more "context"
composition (where Junit4 was often stucked to some required rule params or
runner+rule compositions)
So there cn be reasons to migrate for still maintained and in dev project -
like maven and this is why we did for some projects, for others, as Sandra
said, stick to the old java+maven+plugins, no point to migrate.
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 ven. 3 oct. 2025, 14:11, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Thu, Oct 2, 2025 at 9:21 AM Sandra Parsick <sa...@parsick.dev> wrote:
>
> > 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.
>
> You say that like it’s a bad thing. JUnit 3 is a mature, battle
> tested, and bug free product that fully serves its purpose. It works
> in essentially all versions of Java in use today (I think minimum is
> Java 1.1?)) and is thoroughly documented, supported, and understood.
> There haven’t been releases since 2007 because it hasn’t needed a
> release since 2007.
>
> If you want reliable, bug free software, you need to know when to
> stop. Chasing the new shiny is not sufficient reason to release. If
> there’s nothing that needs to be done, (and for JUnit 3 there isn’t),
> then nothing is precisely what you should do. I’ve talked more
> extensively about this here:
>
> https://www.youtube.com/watch?v=XdoUNQTDE_U&t=3745s
>
> JUnit 4 and 5 do not improve on JUnit 3, or each other. They are
> simply two more ways to do the same thing. The improvements I see that
> help developers test code are in supplementary libraries like assert4j
> or Guava Testlib, not the core frameworks. So if a project wants to
> keep using JUnit 3, it should. Burning developer time upgrading is
> irrational.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Tibor Digana <ti...@apache.org>.
Elliote and all,
Regarding the JUnit3 provider in Surefire, my colleagues deleted it a week
ago without a notion that it is not only JUnit3. It contained POJO as well
testing which means that you can test without any framework. Yes, JUnit3
did not need to have a touch for years as I remember because it was a
simple and stable Provider.
Bad luck, I would say!
So this is what I always say, yeah, the people like raising their hands up,
but the problem is that they have no notion about consequences, and then
nobody would like to take responsibilities, and this is not only the IT,
it's everywhere in every area of humans all around the world, it's like a
sickness, and then it's bad. I am very sad!
IMHO the deletion of JUnit3 Provider should be reverted back.
On Fri, Oct 3, 2025 at 2:11 PM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Thu, Oct 2, 2025 at 9:21 AM Sandra Parsick <sa...@parsick.dev> wrote:
>
> > 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.
>
> You say that like it’s a bad thing. JUnit 3 is a mature, battle
> tested, and bug free product that fully serves its purpose. It works
> in essentially all versions of Java in use today (I think minimum is
> Java 1.1?)) and is thoroughly documented, supported, and understood.
> There haven’t been releases since 2007 because it hasn’t needed a
> release since 2007.
>
> If you want reliable, bug free software, you need to know when to
> stop. Chasing the new shiny is not sufficient reason to release. If
> there’s nothing that needs to be done, (and for JUnit 3 there isn’t),
> then nothing is precisely what you should do. I’ve talked more
> extensively about this here:
>
> https://www.youtube.com/watch?v=XdoUNQTDE_U&t=3745s
>
> JUnit 4 and 5 do not improve on JUnit 3, or each other. They are
> simply two more ways to do the same thing. The improvements I see that
> help developers test code are in supplementary libraries like assert4j
> or Guava Testlib, not the core frameworks. So if a project wants to
> keep using JUnit 3, it should. Burning developer time upgrading is
> irrational.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Oct 2, 2025 at 9:21 AM Sandra Parsick <sa...@parsick.dev> wrote:
> 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.
You say that like it’s a bad thing. JUnit 3 is a mature, battle
tested, and bug free product that fully serves its purpose. It works
in essentially all versions of Java in use today (I think minimum is
Java 1.1?)) and is thoroughly documented, supported, and understood.
There haven’t been releases since 2007 because it hasn’t needed a
release since 2007.
If you want reliable, bug free software, you need to know when to
stop. Chasing the new shiny is not sufficient reason to release. If
there’s nothing that needs to be done, (and for JUnit 3 there isn’t),
then nothing is precisely what you should do. I’ve talked more
extensively about this here:
https://www.youtube.com/watch?v=XdoUNQTDE_U&t=3745s
JUnit 4 and 5 do not improve on JUnit 3, or each other. They are
simply two more ways to do the same thing. The improvements I see that
help developers test code are in supplementary libraries like assert4j
or Guava Testlib, not the core frameworks. So if a project wants to
keep using JUnit 3, it should. Burning developer time upgrading is
irrational.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Sandra Parsick <sa...@parsick.dev>.
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 <ol...@apache.org> a écrit :
>
>> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rm...@gmail.com>
>>>> 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 <ol...@apache.org> 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 <
>>>> rmannibucau@gmail.com
>>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <ol...@apache.org> a écrit :
> On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rm...@gmail.com>
> > > 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 <ol...@apache.org> 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 <
> > > rmannibucau@gmail.com
> > > > >
> > > > > 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: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
On Tue, 30 Sept 2025 at 23:38, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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 <rm...@gmail.com>
> > 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 <ol...@apache.org> 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 <
> > rmannibucau@gmail.com
> > > >
> > > > 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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 30 sept. 2025, 14:42, Gary Gregory <ga...@gmail.com> 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.
> Thank you,
> Gary
>
>
> On Tue, Sep 30, 2025, 06:20 Romain Manni-Bucau <rm...@gmail.com>
> 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 <ol...@apache.org> 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 <
> rmannibucau@gmail.com
> > >
> > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Gary Gregory <ga...@gmail.com>.
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 <rm...@gmail.com>
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 <ol...@apache.org> 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 <rmannibucau@gmail.com
> >
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ol...@apache.org> 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 <rm...@gmail.com>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
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 <rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire way forward ( Re: Maven 4 and surefire/failsafe drop?)
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
On Thu, 6 Nov 2025 at 01:32, Jon Harper <jo...@gmail.com> wrote:
>
> Hi,
> reading this discussion, it made me think of one of the (I think very
> important) missing features when using junit5 and surefire: you can't
> run a single parameterized test on the command line (-Dtest=pattern)
>
> For junit4, there was a syntax like this (see
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test
> "The Parameterized JUnit runner describes test methods using an index
> in brackets, so the non-regex method pattern would become:
> #testMethod[*]. If using @Parameters(name="{index}: fib({0})={1}") and
> selecting the index e.g. 5 in pattern, the non-regex method pattern
> would become #testMethod[5:*]."
>
> But last time I looked, the parameterized patterns were just never
> implemented for junit5, surefire just checks the pattern against the
> methodsource name:
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/TestMethodFilter.java#L51-L53
> .
> Personally this forces me to load the project in eclipse just to be
> able to rightclick on one of the parameterized tests.
>
> Do you think this problem would go away as part of this migration ? I
> never found an issue for this but maybe someone knows if there's one
> already ? Otherwise I can create one if that helps.
>
This will not go away and need to be implemented for JUnit 5 :)
So yes if you can created an issues this would be great (and add a
very simple reproducer might help even more)
> (By the way I see that the docs are outdated "-Dtest=MyTest#myMethod.
> This is supported for junit 4.x and TestNg." but this is also
> supported by junit5 tests currently. Do you want me to do a PR for the
I will fix this quickly in the migration PR
> docs, or can someone else quickly udpate them ? Mentionning that
> junit5 doesn't support the parameterized tests pattern explicitly
> would also help I think, I remember losing a few hours desperately
> trying to get the junit4 patterns to work with junit5 parameterized
> tests out of ignorance)
>
> Cheers,
> Jon
>
> On Wed, Oct 15, 2025 at 4:24 AM Olivier Lamy <ol...@apache.org> wrote:
> >
> > Thanks, Delany. Your message perfectly reflects my own opinion, even
> > as a long-time committer on the project.
> >
> > We never really closed this thread with a clear conclusion or next
> > steps, so I’d like to summarize the current state and propose a path
> > forward.
> >
> > From the discussion so far, there seems to be a general consensus on
> > simplifying Surefire’s codebase by migrating test execution to the
> > JUnit Platform engine. This would be done in a moderately conservative
> > way, as described earlier in this thread:
> > https://lists.apache.org/thread/vovj7srtpjlk67z7ocowzbz3g3z3878t
> >
> > Quick Summary of the current situation:
> > Surefire currently runs tests through multiple provider modules (JUnit
> > 3, 4, 5, TestNG, etc.). Each provider implements similar interfaces
> > and classes, which means that any change to reporters or listeners
> > requires parallel updates across all providers.
> > This architecture made sense in the past, when there wasn’t a unified
> > way to run JUnit 3, JUnit 4, TestNG, and JUnit 5 tests. However, it
> > now results in significant code duplication and added complexity
> > whenever changes are made.
> >
> > Proposed approach:
> > A few years ago, the JUnit team introduced the JUnit Platform, which
> > can run not only JUnit 5 tests (as used by the junit-platform
> > provider) but also JUnit 3, 4, and TestNG tests.
> > To simplify the codebase, we propose removing the dedicated providers
> > for JUnit 3, 4, and TestNG, and using the junit-platform provider as
> > the single unified test runner. Please note the provider architecture
> > is still supported so everybody is free to implement/run their own but
> > we need to stop maintaining so many.
> >
> >
> > This change would mean that JUnit versions older than 4.12 will no
> > longer be supported.
> > However, existing JUnit 3 and JUnit 4 tests (≤ 4.11) can still be
> > executed without modification by simply upgrading the JUnit dependency
> > to at least version 4.12.
> >
> > Reference:
> > A work-in-progress PR is available here:
> > https://github.com/apache/maven-surefire/pull/3179
> >
> > Even if it’s a significant PR with still work to do (Thanks,
> > Sebastian, for his help), which removes a considerable amount of
> > legacy code, it seems to be the way to go and represents some
> > consensus reached with this thread.
> >
> > Onward
> > Olivier
> >
> >
> > On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
> > >
> > > Hi Tibor,
> > >
> > > Another popular principle out there is do one thing well.
> > > The provider principle is already in play with Maven's plugin architecture.
> > >
> > > I would much rather have a test plugin purpose built for the test framework
> > > I use.
> > > Its fine until you want to do something a bit extra,
> > > https://github.com/apache/maven-surefire/issues/3146
> > >
> > > Without knowing anything about the internals, my perception is that
> > > surefire is hugely complicated with a lot of needless ceremony.
> > > I don't feel that way about any other plugin.
> > > You talk about separation of concerns, but at least from the outside it
> > > seems so many concerns are overlapping.
> > > Configuration, test discovery. Threading is configurable in all three,
> > > junit, surefire, and maven, not to mention the unit under test.
> > >
> > > The gold standard is if test frameworks provide their own plugin so there
> > > is clear responsibility for it, and maybe a plugin that shares its namesake
> > > will encourage some buy-in.
> > > If the lineage of developers maintaining the plugin is patchy, what hope is
> > > there for supporting a particular test framework integration,
> > > or looking into deeper issues, or just having some time to respond?
> > >
> > > I probably shouldn't talk about contributing code, but I think designing a
> > > plugin that people would want to contribute should be pretty high on the
> > > list of priorities.
> > > Keeping it lean and fit for purpose should keep the number of releases down
> > > too. Its a busy plugin. Probably the busiest?
> > >
> > > Delany
> > >
> > > On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
> > >
> > > > @Martin Desruisseaux,
> > > >
> > > > >> Even if Maven wanted to be independent of JUnit 5...
> > > > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > > > talking about technical things. I am talking about totally different
> > > > topics, especially about good Surefire purpose and design with Providers,
> > > > risk management and the whole globe of users.
> > > > JUnit5 is not a principal shift.
> > > >
> > > > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > > > 4 + TestNG is intentionally a bad idea.
> > > > The thing happening now goes against the historical continuity because
> > > > previous two developers left ASF.
> > > > - The Surefire originators who designed the architecture had a good
> > > > reasons to introduce Provider API, it is a good design. It separates
> > > > concerns of the plugin from the concerns of test frameworks. Although
> > > > the
> > > > test frameworks have very similar Listeners, they are cohesive with
> > > > Surefire Listener and this enables Maven + plugin to be independent of
> > > > test
> > > > framework implementation across vendors and versions and third party
> > > > policies (pricing, license, SDLC) and this provides us with certain
> > > > freedom
> > > > meaning no coupling (technical coupling and team coupling) between Maven
> > > > plugin and third party frameworks.
> > > >
> > > > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > through JUnit 5 API) has a cost.
> > > > No, this is not true.
> > > > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > > > was stable which means I did not need to touch it for quite a long time.
> > > > This Provider is pretty simple for simple tests, and the positive is that
> > > > the POJO does not require JUnit, this is good for lightweight test
> > > > projects.
> > > >
> > > >
> > > > >> Of course there is a risk that we break something. ... difficult to
> > > > implement.
> > > > It is not difficult to implement. I know Surefire like my shoes.
> > > > My problem is that I left during Covid and the historical continuity with
> > > > new developers was broken, that's my fault, I am honest now. If this did
> > > > not happen then most probably Slawomir would continue straight ahead and
> > > > others maybe too.
> > > >
> > > > Cheers
> > > > Tibor
> > > >
> > > > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > > > <ma...@geomatys.com.invalid> wrote:
> > > >
> > > > > Hello Tibor
> > > > >
> > > > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > > > to invent its own test API. JUnit5 has a separation between API and
> > > > > implementations, so it would be possible to use only the API part if
> > > > > necessary (I don't think that it would be necessary, just mentioning
> > > > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > > > would not necessarily make us fully prisoner of JUnit 5.
> > > > >
> > > > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > > > mailing list for testing the different versions of a multi-release JAR
> > > > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > > > testing time, because Surefire runs the tests with the `*.class` files
> > > > > on the class-path while multi-release works only with JAR files. Last
> > > > > Saturday, I wanted to start looking for the possibility of adding an
> > > > > option for running the tests many times with different
> > > > > `META-INF/versions/*` directories added to the class-path. It was not
> > > > > easy to find my way in the Surefire code, and I rely a lot on the
> > > > > simplification proposed by Romain before to make any other attempt.
> > > > >
> > > > > Of course there is a risk that we break something. But the example given
> > > > > in the previous email (tests as POJO) should be easy to port. The
> > > > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > > > the Surefire plugin: no accidental lost of feature, but also less new
> > > > > features (e.g. easier testing of multi-release projects) because they
> > > > > would be more difficult to implement.
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > > > Romain,
> > > > > >
> > > > > > to be honest the JUnit guys always wanted to make their own business
> > > > and
> > > > > > monopoly over the testing phase in Maven, which means using JUnit5
> > > > only,
> > > > > > that's it.
> > > > > >
> > > > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > > > other.
> > > > > > If I say business then I really mean business and not only the word.
> > > > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > > > still the same competition problems between us, and I say it's about
> > > > the
> > > > > > monopoly, which means who takes the control over these things takes
> > > > full
> > > > > > control over Maven testing and then Maven becomes completely dependent
> > > > on
> > > > > > some test framework which is the risk for Maven.
> > > > > >
> > > > > > This is the main problem but you wouldn't see this unless you have
> > > > spent
> > > > > > years and years developing both parties as I have.
> > > > > >
> > > > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > > > ever, I am telling you!
> > > > > > Btw, experienced Maven guys must know what a strict dependency means
> > > > and
> > > > > > the consequences too.
> > > > > > We are still in the loop for years with deleting something because
> > > > > somebody
> > > > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > > > anything else, some tool or technology as many other, those tools which
> > > > > > come and go every year.
> > > > > >
> > > > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > 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?
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire way forward ( Re: Maven 4 and surefire/failsafe drop?)
Posted by Jon Harper <jo...@gmail.com>.
Hi,
reading this discussion, it made me think of one of the (I think very
important) missing features when using junit5 and surefire: you can't
run a single parameterized test on the command line (-Dtest=pattern)
For junit4, there was a syntax like this (see
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#test
"The Parameterized JUnit runner describes test methods using an index
in brackets, so the non-regex method pattern would become:
#testMethod[*]. If using @Parameters(name="{index}: fib({0})={1}") and
selecting the index e.g. 5 in pattern, the non-regex method pattern
would become #testMethod[5:*]."
But last time I looked, the parameterized patterns were just never
implemented for junit5, surefire just checks the pattern against the
methodsource name:
https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/TestMethodFilter.java#L51-L53
.
Personally this forces me to load the project in eclipse just to be
able to rightclick on one of the parameterized tests.
Do you think this problem would go away as part of this migration ? I
never found an issue for this but maybe someone knows if there's one
already ? Otherwise I can create one if that helps.
(By the way I see that the docs are outdated "-Dtest=MyTest#myMethod.
This is supported for junit 4.x and TestNg." but this is also
supported by junit5 tests currently. Do you want me to do a PR for the
docs, or can someone else quickly udpate them ? Mentionning that
junit5 doesn't support the parameterized tests pattern explicitly
would also help I think, I remember losing a few hours desperately
trying to get the junit4 patterns to work with junit5 parameterized
tests out of ignorance)
Cheers,
Jon
On Wed, Oct 15, 2025 at 4:24 AM Olivier Lamy <ol...@apache.org> wrote:
>
> Thanks, Delany. Your message perfectly reflects my own opinion, even
> as a long-time committer on the project.
>
> We never really closed this thread with a clear conclusion or next
> steps, so I’d like to summarize the current state and propose a path
> forward.
>
> From the discussion so far, there seems to be a general consensus on
> simplifying Surefire’s codebase by migrating test execution to the
> JUnit Platform engine. This would be done in a moderately conservative
> way, as described earlier in this thread:
> https://lists.apache.org/thread/vovj7srtpjlk67z7ocowzbz3g3z3878t
>
> Quick Summary of the current situation:
> Surefire currently runs tests through multiple provider modules (JUnit
> 3, 4, 5, TestNG, etc.). Each provider implements similar interfaces
> and classes, which means that any change to reporters or listeners
> requires parallel updates across all providers.
> This architecture made sense in the past, when there wasn’t a unified
> way to run JUnit 3, JUnit 4, TestNG, and JUnit 5 tests. However, it
> now results in significant code duplication and added complexity
> whenever changes are made.
>
> Proposed approach:
> A few years ago, the JUnit team introduced the JUnit Platform, which
> can run not only JUnit 5 tests (as used by the junit-platform
> provider) but also JUnit 3, 4, and TestNG tests.
> To simplify the codebase, we propose removing the dedicated providers
> for JUnit 3, 4, and TestNG, and using the junit-platform provider as
> the single unified test runner. Please note the provider architecture
> is still supported so everybody is free to implement/run their own but
> we need to stop maintaining so many.
>
>
> This change would mean that JUnit versions older than 4.12 will no
> longer be supported.
> However, existing JUnit 3 and JUnit 4 tests (≤ 4.11) can still be
> executed without modification by simply upgrading the JUnit dependency
> to at least version 4.12.
>
> Reference:
> A work-in-progress PR is available here:
> https://github.com/apache/maven-surefire/pull/3179
>
> Even if it’s a significant PR with still work to do (Thanks,
> Sebastian, for his help), which removes a considerable amount of
> legacy code, it seems to be the way to go and represents some
> consensus reached with this thread.
>
> Onward
> Olivier
>
>
> On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
> >
> > Hi Tibor,
> >
> > Another popular principle out there is do one thing well.
> > The provider principle is already in play with Maven's plugin architecture.
> >
> > I would much rather have a test plugin purpose built for the test framework
> > I use.
> > Its fine until you want to do something a bit extra,
> > https://github.com/apache/maven-surefire/issues/3146
> >
> > Without knowing anything about the internals, my perception is that
> > surefire is hugely complicated with a lot of needless ceremony.
> > I don't feel that way about any other plugin.
> > You talk about separation of concerns, but at least from the outside it
> > seems so many concerns are overlapping.
> > Configuration, test discovery. Threading is configurable in all three,
> > junit, surefire, and maven, not to mention the unit under test.
> >
> > The gold standard is if test frameworks provide their own plugin so there
> > is clear responsibility for it, and maybe a plugin that shares its namesake
> > will encourage some buy-in.
> > If the lineage of developers maintaining the plugin is patchy, what hope is
> > there for supporting a particular test framework integration,
> > or looking into deeper issues, or just having some time to respond?
> >
> > I probably shouldn't talk about contributing code, but I think designing a
> > plugin that people would want to contribute should be pretty high on the
> > list of priorities.
> > Keeping it lean and fit for purpose should keep the number of releases down
> > too. Its a busy plugin. Probably the busiest?
> >
> > Delany
> >
> > On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
> >
> > > @Martin Desruisseaux,
> > >
> > > >> Even if Maven wanted to be independent of JUnit 5...
> > > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > > talking about technical things. I am talking about totally different
> > > topics, especially about good Surefire purpose and design with Providers,
> > > risk management and the whole globe of users.
> > > JUnit5 is not a principal shift.
> > >
> > > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > > 4 + TestNG is intentionally a bad idea.
> > > The thing happening now goes against the historical continuity because
> > > previous two developers left ASF.
> > > - The Surefire originators who designed the architecture had a good
> > > reasons to introduce Provider API, it is a good design. It separates
> > > concerns of the plugin from the concerns of test frameworks. Although
> > > the
> > > test frameworks have very similar Listeners, they are cohesive with
> > > Surefire Listener and this enables Maven + plugin to be independent of
> > > test
> > > framework implementation across vendors and versions and third party
> > > policies (pricing, license, SDLC) and this provides us with certain
> > > freedom
> > > meaning no coupling (technical coupling and team coupling) between Maven
> > > plugin and third party frameworks.
> > >
> > > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > > through JUnit 5 API) has a cost.
> > > No, this is not true.
> > > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > > was stable which means I did not need to touch it for quite a long time.
> > > This Provider is pretty simple for simple tests, and the positive is that
> > > the POJO does not require JUnit, this is good for lightweight test
> > > projects.
> > >
> > >
> > > >> Of course there is a risk that we break something. ... difficult to
> > > implement.
> > > It is not difficult to implement. I know Surefire like my shoes.
> > > My problem is that I left during Covid and the historical continuity with
> > > new developers was broken, that's my fault, I am honest now. If this did
> > > not happen then most probably Slawomir would continue straight ahead and
> > > others maybe too.
> > >
> > > Cheers
> > > Tibor
> > >
> > > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > > <ma...@geomatys.com.invalid> wrote:
> > >
> > > > Hello Tibor
> > > >
> > > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > > to invent its own test API. JUnit5 has a separation between API and
> > > > implementations, so it would be possible to use only the API part if
> > > > necessary (I don't think that it would be necessary, just mentioning
> > > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > > would not necessarily make us fully prisoner of JUnit 5.
> > > >
> > > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > > mailing list for testing the different versions of a multi-release JAR
> > > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > > testing time, because Surefire runs the tests with the `*.class` files
> > > > on the class-path while multi-release works only with JAR files. Last
> > > > Saturday, I wanted to start looking for the possibility of adding an
> > > > option for running the tests many times with different
> > > > `META-INF/versions/*` directories added to the class-path. It was not
> > > > easy to find my way in the Surefire code, and I rely a lot on the
> > > > simplification proposed by Romain before to make any other attempt.
> > > >
> > > > Of course there is a risk that we break something. But the example given
> > > > in the previous email (tests as POJO) should be easy to port. The
> > > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > > the Surefire plugin: no accidental lost of feature, but also less new
> > > > features (e.g. easier testing of multi-release projects) because they
> > > > would be more difficult to implement.
> > > >
> > > > Martin
> > > >
> > > >
> > > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > > Romain,
> > > > >
> > > > > to be honest the JUnit guys always wanted to make their own business
> > > and
> > > > > monopoly over the testing phase in Maven, which means using JUnit5
> > > only,
> > > > > that's it.
> > > > >
> > > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > > other.
> > > > > If I say business then I really mean business and not only the word.
> > > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > > still the same competition problems between us, and I say it's about
> > > the
> > > > > monopoly, which means who takes the control over these things takes
> > > full
> > > > > control over Maven testing and then Maven becomes completely dependent
> > > on
> > > > > some test framework which is the risk for Maven.
> > > > >
> > > > > This is the main problem but you wouldn't see this unless you have
> > > spent
> > > > > years and years developing both parties as I have.
> > > > >
> > > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > > ever, I am telling you!
> > > > > Btw, experienced Maven guys must know what a strict dependency means
> > > and
> > > > > the consequences too.
> > > > > We are still in the loop for years with deleting something because
> > > > somebody
> > > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > > anything else, some tool or technology as many other, those tools which
> > > > > come and go every year.
> > > > >
> > > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > 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?
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Surefire way forward ( Re: Maven 4 and surefire/failsafe drop?)
Posted by Olivier Lamy <ol...@apache.org>.
Thanks, Delany. Your message perfectly reflects my own opinion, even
as a long-time committer on the project.
We never really closed this thread with a clear conclusion or next
steps, so I’d like to summarize the current state and propose a path
forward.
From the discussion so far, there seems to be a general consensus on
simplifying Surefire’s codebase by migrating test execution to the
JUnit Platform engine. This would be done in a moderately conservative
way, as described earlier in this thread:
https://lists.apache.org/thread/vovj7srtpjlk67z7ocowzbz3g3z3878t
Quick Summary of the current situation:
Surefire currently runs tests through multiple provider modules (JUnit
3, 4, 5, TestNG, etc.). Each provider implements similar interfaces
and classes, which means that any change to reporters or listeners
requires parallel updates across all providers.
This architecture made sense in the past, when there wasn’t a unified
way to run JUnit 3, JUnit 4, TestNG, and JUnit 5 tests. However, it
now results in significant code duplication and added complexity
whenever changes are made.
Proposed approach:
A few years ago, the JUnit team introduced the JUnit Platform, which
can run not only JUnit 5 tests (as used by the junit-platform
provider) but also JUnit 3, 4, and TestNG tests.
To simplify the codebase, we propose removing the dedicated providers
for JUnit 3, 4, and TestNG, and using the junit-platform provider as
the single unified test runner. Please note the provider architecture
is still supported so everybody is free to implement/run their own but
we need to stop maintaining so many.
This change would mean that JUnit versions older than 4.12 will no
longer be supported.
However, existing JUnit 3 and JUnit 4 tests (≤ 4.11) can still be
executed without modification by simply upgrading the JUnit dependency
to at least version 4.12.
Reference:
A work-in-progress PR is available here:
https://github.com/apache/maven-surefire/pull/3179
Even if it’s a significant PR with still work to do (Thanks,
Sebastian, for his help), which removes a considerable amount of
legacy code, it seems to be the way to go and represents some
consensus reached with this thread.
Onward
Olivier
On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
>
> Hi Tibor,
>
> Another popular principle out there is do one thing well.
> The provider principle is already in play with Maven's plugin architecture.
>
> I would much rather have a test plugin purpose built for the test framework
> I use.
> Its fine until you want to do something a bit extra,
> https://github.com/apache/maven-surefire/issues/3146
>
> Without knowing anything about the internals, my perception is that
> surefire is hugely complicated with a lot of needless ceremony.
> I don't feel that way about any other plugin.
> You talk about separation of concerns, but at least from the outside it
> seems so many concerns are overlapping.
> Configuration, test discovery. Threading is configurable in all three,
> junit, surefire, and maven, not to mention the unit under test.
>
> The gold standard is if test frameworks provide their own plugin so there
> is clear responsibility for it, and maybe a plugin that shares its namesake
> will encourage some buy-in.
> If the lineage of developers maintaining the plugin is patchy, what hope is
> there for supporting a particular test framework integration,
> or looking into deeper issues, or just having some time to respond?
>
> I probably shouldn't talk about contributing code, but I think designing a
> plugin that people would want to contribute should be pretty high on the
> list of priorities.
> Keeping it lean and fit for purpose should keep the number of releases down
> too. Its a busy plugin. Probably the busiest?
>
> Delany
>
> On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
>
> > @Martin Desruisseaux,
> >
> > >> Even if Maven wanted to be independent of JUnit 5...
> > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > talking about technical things. I am talking about totally different
> > topics, especially about good Surefire purpose and design with Providers,
> > risk management and the whole globe of users.
> > JUnit5 is not a principal shift.
> >
> > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > 4 + TestNG is intentionally a bad idea.
> > The thing happening now goes against the historical continuity because
> > previous two developers left ASF.
> > - The Surefire originators who designed the architecture had a good
> > reasons to introduce Provider API, it is a good design. It separates
> > concerns of the plugin from the concerns of test frameworks. Although
> > the
> > test frameworks have very similar Listeners, they are cohesive with
> > Surefire Listener and this enables Maven + plugin to be independent of
> > test
> > framework implementation across vendors and versions and third party
> > policies (pricing, license, SDLC) and this provides us with certain
> > freedom
> > meaning no coupling (technical coupling and team coupling) between Maven
> > plugin and third party frameworks.
> >
> > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > through JUnit 5 API) has a cost.
> > No, this is not true.
> > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > was stable which means I did not need to touch it for quite a long time.
> > This Provider is pretty simple for simple tests, and the positive is that
> > the POJO does not require JUnit, this is good for lightweight test
> > projects.
> >
> >
> > >> Of course there is a risk that we break something. ... difficult to
> > implement.
> > It is not difficult to implement. I know Surefire like my shoes.
> > My problem is that I left during Covid and the historical continuity with
> > new developers was broken, that's my fault, I am honest now. If this did
> > not happen then most probably Slawomir would continue straight ahead and
> > others maybe too.
> >
> > Cheers
> > Tibor
> >
> > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > <ma...@geomatys.com.invalid> wrote:
> >
> > > Hello Tibor
> > >
> > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > to invent its own test API. JUnit5 has a separation between API and
> > > implementations, so it would be possible to use only the API part if
> > > necessary (I don't think that it would be necessary, just mentioning
> > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > would not necessarily make us fully prisoner of JUnit 5.
> > >
> > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > mailing list for testing the different versions of a multi-release JAR
> > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > testing time, because Surefire runs the tests with the `*.class` files
> > > on the class-path while multi-release works only with JAR files. Last
> > > Saturday, I wanted to start looking for the possibility of adding an
> > > option for running the tests many times with different
> > > `META-INF/versions/*` directories added to the class-path. It was not
> > > easy to find my way in the Surefire code, and I rely a lot on the
> > > simplification proposed by Romain before to make any other attempt.
> > >
> > > Of course there is a risk that we break something. But the example given
> > > in the previous email (tests as POJO) should be easy to port. The
> > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > the Surefire plugin: no accidental lost of feature, but also less new
> > > features (e.g. easier testing of multi-release projects) because they
> > > would be more difficult to implement.
> > >
> > > Martin
> > >
> > >
> > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > Romain,
> > > >
> > > > to be honest the JUnit guys always wanted to make their own business
> > and
> > > > monopoly over the testing phase in Maven, which means using JUnit5
> > only,
> > > > that's it.
> > > >
> > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > other.
> > > > If I say business then I really mean business and not only the word.
> > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > still the same competition problems between us, and I say it's about
> > the
> > > > monopoly, which means who takes the control over these things takes
> > full
> > > > control over Maven testing and then Maven becomes completely dependent
> > on
> > > > some test framework which is the risk for Maven.
> > > >
> > > > This is the main problem but you wouldn't see this unless you have
> > spent
> > > > years and years developing both parties as I have.
> > > >
> > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > ever, I am telling you!
> > > > Btw, experienced Maven guys must know what a strict dependency means
> > and
> > > > the consequences too.
> > > > We are still in the loop for years with deleting something because
> > > somebody
> > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > anything else, some tool or technology as many other, those tools which
> > > > come and go every year.
> > > >
> > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > 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?
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Michael Osipov <mi...@apache.org>.
On 2026/03/01 01:24:45 Olivier Lamy wrote:
> On Sun, 1 Mar 2026 at 09:12, Michael Osipov <mi...@apache.org> wrote:
> >
> > On 2026/02/04 01:48:18 Olivier Lamy wrote:
> > > Hi there,
> > > Finally back after a few months of work (Thanks a lot to Sebastian
> > > Tiemann for the huge help on this topic!), the branch is ready.
> > > There is still a weird Windows test failure.
> > > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > > wmic for Windows.
> > > This wmic looks to be broken on modern Windows see [1].
> > > But I have a very very limited knowledge of this operating system, so
> > > relying on ProcessHandle would be much simpler (sorry the off-topic
> > > this could of another thread but I like to express my frustration via
> > > some ranting :) )
> > >
> > > So what I would like to do now as a plan to move forward:
> > > - make release of master (3.5.5)
> > > - having a 3.5.x branch
> > > - merge the giant PR (master will be 3.6.x) having something 4.0.x
> > > could be better when we will be using Maven 4.x api.
> > > - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> > > as I expect a significant amount of issues even if we have a very
> > > large collection of ITs)
> > > - then fixing the bugs :) for another release. (looping here)
> > >
> > > WDYT?
> >
> > As someone who has worked on Surefire for quite some time I do not fully understand your motivation. I do understand that ProcessHandle will make life easier -- true, but the PpidHandler is just fraction of Surefire there is so much more that is not tied to the Maven version at all. The plugin is just the glue to make it run within Maven. To my understanding, 90% is agnostic and maintaining two branches 4.x and 3.x for just the tip of the iceberg seems too much effort.
> >
> > Can you explain what would actually be an improvement to Surefire -- next to ProcessHandle -- when Maven 4 related changes are done?
> >
>
> The main motivation for the branches isn't related to Maven 4 or the
> ProcessHandle change (which is a minor issue in the grand scheme of
> things).
> The real driver is the significant simplification of the code through
> the removal of obsolete providers.
> These can be replaced by a single one, which greatly streamlines the
> codebase (see PR[1] and the many discussions in this thread; there’s
> been broad agreement across the community on this direction; I don't
> think we need to reopen this discussion).
> The plan I have in mind, and I expect this to stay for quite a while:
> - maven-3.5.x (stable branch from last 3.5.5)
> - master (with the simplification PR merged), which will have 3.6.x versioning.
>
> In the long term (but only until the master branch stabilises),
> something similar to what we do for other "core" plugins (compiler,
> resources, clean, etc.) could be implemented. Like those plugins, the
> master branch could support Maven 4 APIs, allowing for a maven-3.x
> branch.
> But that’s well down the track. I probably shouldn’t have mentioned it
> earlier, as I might’ve just added a bit of confusion and noise :)
>
> Regarding PpidHandler, it's unrelated to the branches strategy; I'm
> unsure where the confusion is. As you mentioned, I agree it's a very
> small part of Surefire, and it’s not even enabled by default, so it's
> probably not really a factor in this discussion.
>
> Hopefully, that clears things up and answers your question. Happy to
> clarify further if needed.
Thank you for taking taking the time to elaborate. Now I fully understand your intentions and support them.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
On Sun, 1 Mar 2026 at 09:12, Michael Osipov <mi...@apache.org> wrote:
>
> On 2026/02/04 01:48:18 Olivier Lamy wrote:
> > Hi there,
> > Finally back after a few months of work (Thanks a lot to Sebastian
> > Tiemann for the huge help on this topic!), the branch is ready.
> > There is still a weird Windows test failure.
> > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > wmic for Windows.
> > This wmic looks to be broken on modern Windows see [1].
> > But I have a very very limited knowledge of this operating system, so
> > relying on ProcessHandle would be much simpler (sorry the off-topic
> > this could of another thread but I like to express my frustration via
> > some ranting :) )
> >
> > So what I would like to do now as a plan to move forward:
> > - make release of master (3.5.5)
> > - having a 3.5.x branch
> > - merge the giant PR (master will be 3.6.x) having something 4.0.x
> > could be better when we will be using Maven 4.x api.
> > - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> > as I expect a significant amount of issues even if we have a very
> > large collection of ITs)
> > - then fixing the bugs :) for another release. (looping here)
> >
> > WDYT?
>
> As someone who has worked on Surefire for quite some time I do not fully understand your motivation. I do understand that ProcessHandle will make life easier -- true, but the PpidHandler is just fraction of Surefire there is so much more that is not tied to the Maven version at all. The plugin is just the glue to make it run within Maven. To my understanding, 90% is agnostic and maintaining two branches 4.x and 3.x for just the tip of the iceberg seems too much effort.
>
> Can you explain what would actually be an improvement to Surefire -- next to ProcessHandle -- when Maven 4 related changes are done?
>
The main motivation for the branches isn't related to Maven 4 or the
ProcessHandle change (which is a minor issue in the grand scheme of
things).
The real driver is the significant simplification of the code through
the removal of obsolete providers.
These can be replaced by a single one, which greatly streamlines the
codebase (see PR[1] and the many discussions in this thread; there’s
been broad agreement across the community on this direction; I don't
think we need to reopen this discussion).
The plan I have in mind, and I expect this to stay for quite a while:
- maven-3.5.x (stable branch from last 3.5.5)
- master (with the simplification PR merged), which will have 3.6.x versioning.
In the long term (but only until the master branch stabilises),
something similar to what we do for other "core" plugins (compiler,
resources, clean, etc.) could be implemented. Like those plugins, the
master branch could support Maven 4 APIs, allowing for a maven-3.x
branch.
But that’s well down the track. I probably shouldn’t have mentioned it
earlier, as I might’ve just added a bit of confusion and noise :)
Regarding PpidHandler, it's unrelated to the branches strategy; I'm
unsure where the confusion is. As you mentioned, I agree it's a very
small part of Surefire, and it’s not even enabled by default, so it's
probably not really a factor in this discussion.
Hopefully, that clears things up and answers your question. Happy to
clarify further if needed.
Cheers,
Olivier
[1] https://github.com/apache/maven-surefire/pull/3179
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Michael Osipov <mi...@apache.org>.
On 2026/02/04 01:48:18 Olivier Lamy wrote:
> Hi there,
> Finally back after a few months of work (Thanks a lot to Sebastian
> Tiemann for the huge help on this topic!), the branch is ready.
> There is still a weird Windows test failure.
> I wish we could be Java 9+ to be able to use ProcessHandle and really
> simplify the class PpidChecker, which mixes parsing of ps on unix and
> wmic for Windows.
> This wmic looks to be broken on modern Windows see [1].
> But I have a very very limited knowledge of this operating system, so
> relying on ProcessHandle would be much simpler (sorry the off-topic
> this could of another thread but I like to express my frustration via
> some ranting :) )
>
> So what I would like to do now as a plan to move forward:
> - make release of master (3.5.5)
> - having a 3.5.x branch
> - merge the giant PR (master will be 3.6.x) having something 4.0.x
> could be better when we will be using Maven 4.x api.
> - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> as I expect a significant amount of issues even if we have a very
> large collection of ITs)
> - then fixing the bugs :) for another release. (looping here)
>
> WDYT?
As someone who has worked on Surefire for quite some time I do not fully understand your motivation. I do understand that ProcessHandle will make life easier -- true, but the PpidHandler is just fraction of Surefire there is so much more that is not tied to the Maven version at all. The plugin is just the glue to make it run within Maven. To my understanding, 90% is agnostic and maintaining two branches 4.x and 3.x for just the tip of the iceberg seems too much effort.
Can you explain what would actually be an improvement to Surefire -- next to ProcessHandle -- when Maven 4 related changes are done?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
On Sun, 22 Feb 2026 at 21:45, Olivier Lamy <ol...@apache.org> wrote:
>
> Hi,
> As discussed here and due to the major consensus, I will move forward
> with the plan.
> See inline
>
>
> On Wed, 4 Feb 2026 at 11:48, Olivier Lamy <ol...@apache.org> wrote:
> >
> > Hi there,
> > Finally back after a few months of work (Thanks a lot to Sebastian
> > Tiemann for the huge help on this topic!), the branch is ready.
> > There is still a weird Windows test failure.
> > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > wmic for Windows.
> > This wmic looks to be broken on modern Windows see [1].
> > But I have a very very limited knowledge of this operating system, so
> > relying on ProcessHandle would be much simpler (sorry the off-topic
> > this could of another thread but I like to express my frustration via
> > some ranting :) )
> >
> > So what I would like to do now as a plan to move forward:
> > - make release of master (3.5.5)
>
> Done
>
> > - having a 3.5.x branch
>
> branch surefire-3.5.x created
>
>
> > - merge the giant PR (master will be 3.6.x) having something 4.0.x
> > could be better when we will be using Maven 4.x api.
>
Just a reminder about the work in progress here
The goal is to merge the huge PR by the end of the week (Sunday)
(https://github.com/apache/maven-surefire/pull/3179)
I'm sorry that's very big (a lot of code deletion), but not sure how
to do it differently (not something you can do by increments)
> finishing/magnifying changes in the PR (the huge part of the work is
> done) (https://github.com/apache/maven-surefire/pull/3179)
> I have added some documentation with mermaid diagrams (which are
> rendering well in GitHub but still need a PR to get merged and doxia
> tools released for good rendering with Maven website)
>
>
> > - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> > as I expect a significant amount of issues even if we have a very
> > large collection of ITs)
> > - then fixing the bugs :) for another release. (looping here)
> >
> > WDYT?
> >
> > Cheers
> > Olivier
> >
> > [1] https://github.com/apache/maven-surefire/issues/3176
> >
> >
> > On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
> > >
> > > Hi Tibor,
> > >
> > > Another popular principle out there is do one thing well.
> > > The provider principle is already in play with Maven's plugin architecture.
> > >
> > > I would much rather have a test plugin purpose built for the test framework
> > > I use.
> > > Its fine until you want to do something a bit extra,
> > > https://github.com/apache/maven-surefire/issues/3146
> > >
> > > Without knowing anything about the internals, my perception is that
> > > surefire is hugely complicated with a lot of needless ceremony.
> > > I don't feel that way about any other plugin.
> > > You talk about separation of concerns, but at least from the outside it
> > > seems so many concerns are overlapping.
> > > Configuration, test discovery. Threading is configurable in all three,
> > > junit, surefire, and maven, not to mention the unit under test.
> > >
> > > The gold standard is if test frameworks provide their own plugin so there
> > > is clear responsibility for it, and maybe a plugin that shares its namesake
> > > will encourage some buy-in.
> > > If the lineage of developers maintaining the plugin is patchy, what hope is
> > > there for supporting a particular test framework integration,
> > > or looking into deeper issues, or just having some time to respond?
> > >
> > > I probably shouldn't talk about contributing code, but I think designing a
> > > plugin that people would want to contribute should be pretty high on the
> > > list of priorities.
> > > Keeping it lean and fit for purpose should keep the number of releases down
> > > too. Its a busy plugin. Probably the busiest?
> > >
> > > Delany
> > >
> > > On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
> > >
> > > > @Martin Desruisseaux,
> > > >
> > > > >> Even if Maven wanted to be independent of JUnit 5...
> > > > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > > > talking about technical things. I am talking about totally different
> > > > topics, especially about good Surefire purpose and design with Providers,
> > > > risk management and the whole globe of users.
> > > > JUnit5 is not a principal shift.
> > > >
> > > > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > > > 4 + TestNG is intentionally a bad idea.
> > > > The thing happening now goes against the historical continuity because
> > > > previous two developers left ASF.
> > > > - The Surefire originators who designed the architecture had a good
> > > > reasons to introduce Provider API, it is a good design. It separates
> > > > concerns of the plugin from the concerns of test frameworks. Although
> > > > the
> > > > test frameworks have very similar Listeners, they are cohesive with
> > > > Surefire Listener and this enables Maven + plugin to be independent of
> > > > test
> > > > framework implementation across vendors and versions and third party
> > > > policies (pricing, license, SDLC) and this provides us with certain
> > > > freedom
> > > > meaning no coupling (technical coupling and team coupling) between Maven
> > > > plugin and third party frameworks.
> > > >
> > > > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > through JUnit 5 API) has a cost.
> > > > No, this is not true.
> > > > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > > > was stable which means I did not need to touch it for quite a long time.
> > > > This Provider is pretty simple for simple tests, and the positive is that
> > > > the POJO does not require JUnit, this is good for lightweight test
> > > > projects.
> > > >
> > > >
> > > > >> Of course there is a risk that we break something. ... difficult to
> > > > implement.
> > > > It is not difficult to implement. I know Surefire like my shoes.
> > > > My problem is that I left during Covid and the historical continuity with
> > > > new developers was broken, that's my fault, I am honest now. If this did
> > > > not happen then most probably Slawomir would continue straight ahead and
> > > > others maybe too.
> > > >
> > > > Cheers
> > > > Tibor
> > > >
> > > > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > > > <ma...@geomatys.com.invalid> wrote:
> > > >
> > > > > Hello Tibor
> > > > >
> > > > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > > > to invent its own test API. JUnit5 has a separation between API and
> > > > > implementations, so it would be possible to use only the API part if
> > > > > necessary (I don't think that it would be necessary, just mentioning
> > > > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > > > would not necessarily make us fully prisoner of JUnit 5.
> > > > >
> > > > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > > > mailing list for testing the different versions of a multi-release JAR
> > > > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > > > testing time, because Surefire runs the tests with the `*.class` files
> > > > > on the class-path while multi-release works only with JAR files. Last
> > > > > Saturday, I wanted to start looking for the possibility of adding an
> > > > > option for running the tests many times with different
> > > > > `META-INF/versions/*` directories added to the class-path. It was not
> > > > > easy to find my way in the Surefire code, and I rely a lot on the
> > > > > simplification proposed by Romain before to make any other attempt.
> > > > >
> > > > > Of course there is a risk that we break something. But the example given
> > > > > in the previous email (tests as POJO) should be easy to port. The
> > > > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > > > the Surefire plugin: no accidental lost of feature, but also less new
> > > > > features (e.g. easier testing of multi-release projects) because they
> > > > > would be more difficult to implement.
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > > > Romain,
> > > > > >
> > > > > > to be honest the JUnit guys always wanted to make their own business
> > > > and
> > > > > > monopoly over the testing phase in Maven, which means using JUnit5
> > > > only,
> > > > > > that's it.
> > > > > >
> > > > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > > > other.
> > > > > > If I say business then I really mean business and not only the word.
> > > > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > > > still the same competition problems between us, and I say it's about
> > > > the
> > > > > > monopoly, which means who takes the control over these things takes
> > > > full
> > > > > > control over Maven testing and then Maven becomes completely dependent
> > > > on
> > > > > > some test framework which is the risk for Maven.
> > > > > >
> > > > > > This is the main problem but you wouldn't see this unless you have
> > > > spent
> > > > > > years and years developing both parties as I have.
> > > > > >
> > > > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > > > ever, I am telling you!
> > > > > > Btw, experienced Maven guys must know what a strict dependency means
> > > > and
> > > > > > the consequences too.
> > > > > > We are still in the loop for years with deleting something because
> > > > > somebody
> > > > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > > > anything else, some tool or technology as many other, those tools which
> > > > > > come and go every year.
> > > > > >
> > > > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > 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?
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
As discussed here and due to the major consensus, I will move forward
with the plan.
See inline
On Wed, 4 Feb 2026 at 11:48, Olivier Lamy <ol...@apache.org> wrote:
>
> Hi there,
> Finally back after a few months of work (Thanks a lot to Sebastian
> Tiemann for the huge help on this topic!), the branch is ready.
> There is still a weird Windows test failure.
> I wish we could be Java 9+ to be able to use ProcessHandle and really
> simplify the class PpidChecker, which mixes parsing of ps on unix and
> wmic for Windows.
> This wmic looks to be broken on modern Windows see [1].
> But I have a very very limited knowledge of this operating system, so
> relying on ProcessHandle would be much simpler (sorry the off-topic
> this could of another thread but I like to express my frustration via
> some ranting :) )
>
> So what I would like to do now as a plan to move forward:
> - make release of master (3.5.5)
Done
> - having a 3.5.x branch
branch surefire-3.5.x created
> - merge the giant PR (master will be 3.6.x) having something 4.0.x
> could be better when we will be using Maven 4.x api.
finishing/magnifying changes in the PR (the huge part of the work is
done) (https://github.com/apache/maven-surefire/pull/3179)
I have added some documentation with mermaid diagrams (which are
rendering well in GitHub but still need a PR to get merged and doxia
tools released for good rendering with Maven website)
> - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> as I expect a significant amount of issues even if we have a very
> large collection of ITs)
> - then fixing the bugs :) for another release. (looping here)
>
> WDYT?
>
> Cheers
> Olivier
>
> [1] https://github.com/apache/maven-surefire/issues/3176
>
>
> On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
> >
> > Hi Tibor,
> >
> > Another popular principle out there is do one thing well.
> > The provider principle is already in play with Maven's plugin architecture.
> >
> > I would much rather have a test plugin purpose built for the test framework
> > I use.
> > Its fine until you want to do something a bit extra,
> > https://github.com/apache/maven-surefire/issues/3146
> >
> > Without knowing anything about the internals, my perception is that
> > surefire is hugely complicated with a lot of needless ceremony.
> > I don't feel that way about any other plugin.
> > You talk about separation of concerns, but at least from the outside it
> > seems so many concerns are overlapping.
> > Configuration, test discovery. Threading is configurable in all three,
> > junit, surefire, and maven, not to mention the unit under test.
> >
> > The gold standard is if test frameworks provide their own plugin so there
> > is clear responsibility for it, and maybe a plugin that shares its namesake
> > will encourage some buy-in.
> > If the lineage of developers maintaining the plugin is patchy, what hope is
> > there for supporting a particular test framework integration,
> > or looking into deeper issues, or just having some time to respond?
> >
> > I probably shouldn't talk about contributing code, but I think designing a
> > plugin that people would want to contribute should be pretty high on the
> > list of priorities.
> > Keeping it lean and fit for purpose should keep the number of releases down
> > too. Its a busy plugin. Probably the busiest?
> >
> > Delany
> >
> > On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
> >
> > > @Martin Desruisseaux,
> > >
> > > >> Even if Maven wanted to be independent of JUnit 5...
> > > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > > talking about technical things. I am talking about totally different
> > > topics, especially about good Surefire purpose and design with Providers,
> > > risk management and the whole globe of users.
> > > JUnit5 is not a principal shift.
> > >
> > > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > > 4 + TestNG is intentionally a bad idea.
> > > The thing happening now goes against the historical continuity because
> > > previous two developers left ASF.
> > > - The Surefire originators who designed the architecture had a good
> > > reasons to introduce Provider API, it is a good design. It separates
> > > concerns of the plugin from the concerns of test frameworks. Although
> > > the
> > > test frameworks have very similar Listeners, they are cohesive with
> > > Surefire Listener and this enables Maven + plugin to be independent of
> > > test
> > > framework implementation across vendors and versions and third party
> > > policies (pricing, license, SDLC) and this provides us with certain
> > > freedom
> > > meaning no coupling (technical coupling and team coupling) between Maven
> > > plugin and third party frameworks.
> > >
> > > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > > through JUnit 5 API) has a cost.
> > > No, this is not true.
> > > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > > was stable which means I did not need to touch it for quite a long time.
> > > This Provider is pretty simple for simple tests, and the positive is that
> > > the POJO does not require JUnit, this is good for lightweight test
> > > projects.
> > >
> > >
> > > >> Of course there is a risk that we break something. ... difficult to
> > > implement.
> > > It is not difficult to implement. I know Surefire like my shoes.
> > > My problem is that I left during Covid and the historical continuity with
> > > new developers was broken, that's my fault, I am honest now. If this did
> > > not happen then most probably Slawomir would continue straight ahead and
> > > others maybe too.
> > >
> > > Cheers
> > > Tibor
> > >
> > > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > > <ma...@geomatys.com.invalid> wrote:
> > >
> > > > Hello Tibor
> > > >
> > > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > > to invent its own test API. JUnit5 has a separation between API and
> > > > implementations, so it would be possible to use only the API part if
> > > > necessary (I don't think that it would be necessary, just mentioning
> > > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > > would not necessarily make us fully prisoner of JUnit 5.
> > > >
> > > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > > mailing list for testing the different versions of a multi-release JAR
> > > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > > testing time, because Surefire runs the tests with the `*.class` files
> > > > on the class-path while multi-release works only with JAR files. Last
> > > > Saturday, I wanted to start looking for the possibility of adding an
> > > > option for running the tests many times with different
> > > > `META-INF/versions/*` directories added to the class-path. It was not
> > > > easy to find my way in the Surefire code, and I rely a lot on the
> > > > simplification proposed by Romain before to make any other attempt.
> > > >
> > > > Of course there is a risk that we break something. But the example given
> > > > in the previous email (tests as POJO) should be easy to port. The
> > > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > > the Surefire plugin: no accidental lost of feature, but also less new
> > > > features (e.g. easier testing of multi-release projects) because they
> > > > would be more difficult to implement.
> > > >
> > > > Martin
> > > >
> > > >
> > > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > > Romain,
> > > > >
> > > > > to be honest the JUnit guys always wanted to make their own business
> > > and
> > > > > monopoly over the testing phase in Maven, which means using JUnit5
> > > only,
> > > > > that's it.
> > > > >
> > > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > > other.
> > > > > If I say business then I really mean business and not only the word.
> > > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > > still the same competition problems between us, and I say it's about
> > > the
> > > > > monopoly, which means who takes the control over these things takes
> > > full
> > > > > control over Maven testing and then Maven becomes completely dependent
> > > on
> > > > > some test framework which is the risk for Maven.
> > > > >
> > > > > This is the main problem but you wouldn't see this unless you have
> > > spent
> > > > > years and years developing both parties as I have.
> > > > >
> > > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > > ever, I am telling you!
> > > > > Btw, experienced Maven guys must know what a strict dependency means
> > > and
> > > > > the consequences too.
> > > > > We are still in the loop for years with deleting something because
> > > > somebody
> > > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > > anything else, some tool or technology as many other, those tools which
> > > > > come and go every year.
> > > > >
> > > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > 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?
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
+1 for this idea about to focus more on 4.x
śr., 4 lut 2026, 17:52 użytkownik Romain Manni-Bucau <rm...@gmail.com>
napisał:
> +1 to make v3 in maintenance mode and drop the useless abstractions in v4
>
> 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. 4 févr. 2026 à 13:16, Martin Desruisseaux via dev <
> dev@maven.apache.org> a écrit :
>
> > Hello Olivier
> >
> > Thanks a lot for this work!
> >
> > Le 04/02/2026 à 02:48, Olivier Lamy a écrit :
> >
> > > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > > wmic for Windows.
> >
> > If the issue is not considered a blocking issue, maybe we do not need to
> > spend too much energy on the 3.x branch and focus on Maven 4 soon?
> > Alternatively, if resolving this issue on 3.x is considered important
> > enough for being worth the effort, maybe use multi-release?
> >
> > Otherwise, the plan looks good to me. After this simplification, we
> > would hopefully be able to finish Java Module support in a minimal set
> > of Maven plugins. Even if there are many plugins not yet covered, I
> > think that Surefire is the last critical plugin needing update for
> > having a minimal support of Java modules in Maven.
> >
> > Martin
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 to make v3 in maintenance mode and drop the useless abstractions in v4
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. 4 févr. 2026 à 13:16, Martin Desruisseaux via dev <
dev@maven.apache.org> a écrit :
> Hello Olivier
>
> Thanks a lot for this work!
>
> Le 04/02/2026 à 02:48, Olivier Lamy a écrit :
>
> > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > wmic for Windows.
>
> If the issue is not considered a blocking issue, maybe we do not need to
> spend too much energy on the 3.x branch and focus on Maven 4 soon?
> Alternatively, if resolving this issue on 3.x is considered important
> enough for being worth the effort, maybe use multi-release?
>
> Otherwise, the plan looks good to me. After this simplification, we
> would hopefully be able to finish Java Module support in a minimal set
> of Maven plugins. Even if there are many plugins not yet covered, I
> think that Surefire is the last critical plugin needing update for
> having a minimal support of Java modules in Maven.
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
On Wed, 4 Feb 2026 at 22:16, Martin Desruisseaux via dev
<de...@maven.apache.org> wrote:
>
> Hello Olivier
>
> Thanks a lot for this work!
>
> Le 04/02/2026 à 02:48, Olivier Lamy a écrit :
>
> > I wish we could be Java 9+ to be able to use ProcessHandle and really
> > simplify the class PpidChecker, which mixes parsing of ps on unix and
> > wmic for Windows.
>
> If the issue is not considered a blocking issue, maybe we do not need to
> spend too much energy on the 3.x branch and focus on Maven 4 soon?
> Alternatively, if resolving this issue on 3.x is considered important
> enough for being worth the effort, maybe use multi-release?
>
I would say we should do as we do with other plugins etc..;
- 3.x branch (for core 3.x compatibitliy)
- master/main for core api 4.x
> Otherwise, the plan looks good to me. After this simplification, we
> would hopefully be able to finish Java Module support in a minimal set
> of Maven plugins. Even if there are many plugins not yet covered, I
> think that Surefire is the last critical plugin needing update for
> having a minimal support of Java modules in Maven.
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Martin Desruisseaux via dev <de...@maven.apache.org>.
Hello Olivier
Thanks a lot for this work!
Le 04/02/2026 à 02:48, Olivier Lamy a écrit :
> I wish we could be Java 9+ to be able to use ProcessHandle and really
> simplify the class PpidChecker, which mixes parsing of ps on unix and
> wmic for Windows.
If the issue is not considered a blocking issue, maybe we do not need to
spend too much energy on the 3.x branch and focus on Maven 4 soon?
Alternatively, if resolving this issue on 3.x is considered important
enough for being worth the effort, maybe use multi-release?
Otherwise, the plan looks good to me. After this simplification, we
would hopefully be able to finish Java Module support in a minimal set
of Maven plugins. Even if there are many plugins not yet covered, I
think that Surefire is the last critical plugin needing update for
having a minimal support of Java modules in Maven.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Sandra Parsick <sa...@parsick.dev>.
+1, sounds like a solid plan.
Thanks, Olivier and Sebastian, for your hard work.
Am 04.02.26 um 02:48 schrieb Olivier Lamy:
> Hi there,
> Finally back after a few months of work (Thanks a lot to Sebastian
> Tiemann for the huge help on this topic!), the branch is ready.
> There is still a weird Windows test failure.
> I wish we could be Java 9+ to be able to use ProcessHandle and really
> simplify the class PpidChecker, which mixes parsing of ps on unix and
> wmic for Windows.
> This wmic looks to be broken on modern Windows see [1].
> But I have a very very limited knowledge of this operating system, so
> relying on ProcessHandle would be much simpler (sorry the off-topic
> this could of another thread but I like to express my frustration via
> some ranting :) )
>
> So what I would like to do now as a plan to move forward:
> - make release of master (3.5.5)
> - having a 3.5.x branch
> - merge the giant PR (master will be 3.6.x) having something 4.0.x
> could be better when we will be using Maven 4.x api.
> - cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
> as I expect a significant amount of issues even if we have a very
> large collection of ITs)
> - then fixing the bugs :) for another release. (looping here)
>
> WDYT?
>
> Cheers
> Olivier
>
> [1] https://github.com/apache/maven-surefire/issues/3176
>
>
> On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
>>
>> Hi Tibor,
>>
>> Another popular principle out there is do one thing well.
>> The provider principle is already in play with Maven's plugin architecture.
>>
>> I would much rather have a test plugin purpose built for the test framework
>> I use.
>> Its fine until you want to do something a bit extra,
>> https://github.com/apache/maven-surefire/issues/3146
>>
>> Without knowing anything about the internals, my perception is that
>> surefire is hugely complicated with a lot of needless ceremony.
>> I don't feel that way about any other plugin.
>> You talk about separation of concerns, but at least from the outside it
>> seems so many concerns are overlapping.
>> Configuration, test discovery. Threading is configurable in all three,
>> junit, surefire, and maven, not to mention the unit under test.
>>
>> The gold standard is if test frameworks provide their own plugin so there
>> is clear responsibility for it, and maybe a plugin that shares its namesake
>> will encourage some buy-in.
>> If the lineage of developers maintaining the plugin is patchy, what hope is
>> there for supporting a particular test framework integration,
>> or looking into deeper issues, or just having some time to respond?
>>
>> I probably shouldn't talk about contributing code, but I think designing a
>> plugin that people would want to contribute should be pretty high on the
>> list of priorities.
>> Keeping it lean and fit for purpose should keep the number of releases down
>> too. Its a busy plugin. Probably the busiest?
>>
>> Delany
>>
>> On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
>>
>>> @Martin Desruisseaux,
>>>
>>>>> Even if Maven wanted to be independent of JUnit 5...
>>> I know Surefire and JUnit5 quite well, no need to tell me, but I was not
>>> talking about technical things. I am talking about totally different
>>> topics, especially about good Surefire purpose and design with Providers,
>>> risk management and the whole globe of users.
>>> JUnit5 is not a principal shift.
>>>
>>> - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
>>> 4 + TestNG is intentionally a bad idea.
>>> The thing happening now goes against the historical continuity because
>>> previous two developers left ASF.
>>> - The Surefire originators who designed the architecture had a good
>>> reasons to introduce Provider API, it is a good design. It separates
>>> concerns of the plugin from the concerns of test frameworks. Although
>>> the
>>> test frameworks have very similar Listeners, they are cohesive with
>>> Surefire Listener and this enables Maven + plugin to be independent of
>>> test
>>> framework implementation across vendors and versions and third party
>>> policies (pricing, license, SDLC) and this provides us with certain
>>> freedom
>>> meaning no coupling (technical coupling and team coupling) between Maven
>>> plugin and third party frameworks.
>>>
>>>>> Keeping direct support of JUnit 3 (as opposed to indirect support
>>> through JUnit 5 API) has a cost.
>>> No, this is not true.
>>> I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
>>> was stable which means I did not need to touch it for quite a long time.
>>> This Provider is pretty simple for simple tests, and the positive is that
>>> the POJO does not require JUnit, this is good for lightweight test
>>> projects.
>>>
>>>
>>>>> Of course there is a risk that we break something. ... difficult to
>>> implement.
>>> It is not difficult to implement. I know Surefire like my shoes.
>>> My problem is that I left during Covid and the historical continuity with
>>> new developers was broken, that's my fault, I am honest now. If this did
>>> not happen then most probably Slawomir would continue straight ahead and
>>> others maybe too.
>>>
>>> Cheers
>>> Tibor
>>>
>>> On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
>>> <ma...@geomatys.com.invalid> wrote:
>>>
>>>> Hello Tibor
>>>>
>>>> Even if Maven wanted to be independent of JUnit 5, Maven does not need
>>>> to invent its own test API. JUnit5 has a separation between API and
>>>> implementations, so it would be possible to use only the API part if
>>>> necessary (I don't think that it would be necessary, just mentioning
>>>> that we have this possibility). Therefore, a full switch to JUnit 5
>>>> would not necessarily make us fully prisoner of JUnit 5.
>>>>
>>>> Keeping direct support of JUnit 3 (as opposed to indirect support
>>>> through JUnit 5 API) has a cost. For example, I saw requests on this
>>>> mailing list for testing the different versions of a multi-release JAR
>>>> file. Currently, any classes in META-INF/versions/* will be ignored at
>>>> testing time, because Surefire runs the tests with the `*.class` files
>>>> on the class-path while multi-release works only with JAR files. Last
>>>> Saturday, I wanted to start looking for the possibility of adding an
>>>> option for running the tests many times with different
>>>> `META-INF/versions/*` directories added to the class-path. It was not
>>>> easy to find my way in the Surefire code, and I rely a lot on the
>>>> simplification proposed by Romain before to make any other attempt.
>>>>
>>>> Of course there is a risk that we break something. But the example given
>>>> in the previous email (tests as POJO) should be easy to port. The
>>>> alternative (not removing direct JUnit 3 support) is more like freezing
>>>> the Surefire plugin: no accidental lost of feature, but also less new
>>>> features (e.g. easier testing of multi-release projects) because they
>>>> would be more difficult to implement.
>>>>
>>>> Martin
>>>>
>>>>
>>>> Le 07/10/2025 à 19:16, Tibor Digana a écrit :
>>>>> Romain,
>>>>>
>>>>> to be honest the JUnit guys always wanted to make their own business
>>> and
>>>>> monopoly over the testing phase in Maven, which means using JUnit5
>>> only,
>>>>> that's it.
>>>>>
>>>>> I have been a JUnit4 developer since cca 2011 or so, and we know each
>>>> other.
>>>>> If I say business then I really mean business and not only the word.
>>>>> Defining report schema and forking mechanism JVMs in JUnit5, these are
>>>>> still the same competition problems between us, and I say it's about
>>> the
>>>>> monopoly, which means who takes the control over these things takes
>>> full
>>>>> control over Maven testing and then Maven becomes completely dependent
>>> on
>>>>> some test framework which is the risk for Maven.
>>>>>
>>>>> This is the main problem but you wouldn't see this unless you have
>>> spent
>>>>> years and years developing both parties as I have.
>>>>>
>>>>> Making Maven strictly dependent only on JUnit5 is the worst decision
>>>>> ever, I am telling you!
>>>>> Btw, experienced Maven guys must know what a strict dependency means
>>> and
>>>>> the consequences too.
>>>>> We are still in the loop for years with deleting something because
>>>> somebody
>>>>> has got a crazy idea in the morning, found out github/dev-factory or
>>>>> anything else, some tool or technology as many other, those tools which
>>>>> come and go every year.
>>>>>
>>>>> On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>
>>>>> 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?
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
Hi there,
Finally back after a few months of work (Thanks a lot to Sebastian
Tiemann for the huge help on this topic!), the branch is ready.
There is still a weird Windows test failure.
I wish we could be Java 9+ to be able to use ProcessHandle and really
simplify the class PpidChecker, which mixes parsing of ps on unix and
wmic for Windows.
This wmic looks to be broken on modern Windows see [1].
But I have a very very limited knowledge of this operating system, so
relying on ProcessHandle would be much simpler (sorry the off-topic
this could of another thread but I like to express my frustration via
some ranting :) )
So what I would like to do now as a plan to move forward:
- make release of master (3.5.5)
- having a 3.5.x branch
- merge the giant PR (master will be 3.6.x) having something 4.0.x
could be better when we will be using Maven 4.x api.
- cut a release 3.6.0.M1 could be alpha-1, beta-1 (or even broken-1
as I expect a significant amount of issues even if we have a very
large collection of ITs)
- then fixing the bugs :) for another release. (looping here)
WDYT?
Cheers
Olivier
[1] https://github.com/apache/maven-surefire/issues/3176
On Thu, 9 Oct 2025 at 17:23, Delany <de...@gmail.com> wrote:
>
> Hi Tibor,
>
> Another popular principle out there is do one thing well.
> The provider principle is already in play with Maven's plugin architecture.
>
> I would much rather have a test plugin purpose built for the test framework
> I use.
> Its fine until you want to do something a bit extra,
> https://github.com/apache/maven-surefire/issues/3146
>
> Without knowing anything about the internals, my perception is that
> surefire is hugely complicated with a lot of needless ceremony.
> I don't feel that way about any other plugin.
> You talk about separation of concerns, but at least from the outside it
> seems so many concerns are overlapping.
> Configuration, test discovery. Threading is configurable in all three,
> junit, surefire, and maven, not to mention the unit under test.
>
> The gold standard is if test frameworks provide their own plugin so there
> is clear responsibility for it, and maybe a plugin that shares its namesake
> will encourage some buy-in.
> If the lineage of developers maintaining the plugin is patchy, what hope is
> there for supporting a particular test framework integration,
> or looking into deeper issues, or just having some time to respond?
>
> I probably shouldn't talk about contributing code, but I think designing a
> plugin that people would want to contribute should be pretty high on the
> list of priorities.
> Keeping it lean and fit for purpose should keep the number of releases down
> too. Its a busy plugin. Probably the busiest?
>
> Delany
>
> On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
>
> > @Martin Desruisseaux,
> >
> > >> Even if Maven wanted to be independent of JUnit 5...
> > I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> > talking about technical things. I am talking about totally different
> > topics, especially about good Surefire purpose and design with Providers,
> > risk management and the whole globe of users.
> > JUnit5 is not a principal shift.
> >
> > - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> > 4 + TestNG is intentionally a bad idea.
> > The thing happening now goes against the historical continuity because
> > previous two developers left ASF.
> > - The Surefire originators who designed the architecture had a good
> > reasons to introduce Provider API, it is a good design. It separates
> > concerns of the plugin from the concerns of test frameworks. Although
> > the
> > test frameworks have very similar Listeners, they are cohesive with
> > Surefire Listener and this enables Maven + plugin to be independent of
> > test
> > framework implementation across vendors and versions and third party
> > policies (pricing, license, SDLC) and this provides us with certain
> > freedom
> > meaning no coupling (technical coupling and team coupling) between Maven
> > plugin and third party frameworks.
> >
> > >> Keeping direct support of JUnit 3 (as opposed to indirect support
> > through JUnit 5 API) has a cost.
> > No, this is not true.
> > I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> > was stable which means I did not need to touch it for quite a long time.
> > This Provider is pretty simple for simple tests, and the positive is that
> > the POJO does not require JUnit, this is good for lightweight test
> > projects.
> >
> >
> > >> Of course there is a risk that we break something. ... difficult to
> > implement.
> > It is not difficult to implement. I know Surefire like my shoes.
> > My problem is that I left during Covid and the historical continuity with
> > new developers was broken, that's my fault, I am honest now. If this did
> > not happen then most probably Slawomir would continue straight ahead and
> > others maybe too.
> >
> > Cheers
> > Tibor
> >
> > On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> > <ma...@geomatys.com.invalid> wrote:
> >
> > > Hello Tibor
> > >
> > > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > > to invent its own test API. JUnit5 has a separation between API and
> > > implementations, so it would be possible to use only the API part if
> > > necessary (I don't think that it would be necessary, just mentioning
> > > that we have this possibility). Therefore, a full switch to JUnit 5
> > > would not necessarily make us fully prisoner of JUnit 5.
> > >
> > > Keeping direct support of JUnit 3 (as opposed to indirect support
> > > through JUnit 5 API) has a cost. For example, I saw requests on this
> > > mailing list for testing the different versions of a multi-release JAR
> > > file. Currently, any classes in META-INF/versions/* will be ignored at
> > > testing time, because Surefire runs the tests with the `*.class` files
> > > on the class-path while multi-release works only with JAR files. Last
> > > Saturday, I wanted to start looking for the possibility of adding an
> > > option for running the tests many times with different
> > > `META-INF/versions/*` directories added to the class-path. It was not
> > > easy to find my way in the Surefire code, and I rely a lot on the
> > > simplification proposed by Romain before to make any other attempt.
> > >
> > > Of course there is a risk that we break something. But the example given
> > > in the previous email (tests as POJO) should be easy to port. The
> > > alternative (not removing direct JUnit 3 support) is more like freezing
> > > the Surefire plugin: no accidental lost of feature, but also less new
> > > features (e.g. easier testing of multi-release projects) because they
> > > would be more difficult to implement.
> > >
> > > Martin
> > >
> > >
> > > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > > Romain,
> > > >
> > > > to be honest the JUnit guys always wanted to make their own business
> > and
> > > > monopoly over the testing phase in Maven, which means using JUnit5
> > only,
> > > > that's it.
> > > >
> > > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > > other.
> > > > If I say business then I really mean business and not only the word.
> > > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > > still the same competition problems between us, and I say it's about
> > the
> > > > monopoly, which means who takes the control over these things takes
> > full
> > > > control over Maven testing and then Maven becomes completely dependent
> > on
> > > > some test framework which is the risk for Maven.
> > > >
> > > > This is the main problem but you wouldn't see this unless you have
> > spent
> > > > years and years developing both parties as I have.
> > > >
> > > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > > ever, I am telling you!
> > > > Btw, experienced Maven guys must know what a strict dependency means
> > and
> > > > the consequences too.
> > > > We are still in the loop for years with deleting something because
> > > somebody
> > > > has got a crazy idea in the morning, found out github/dev-factory or
> > > > anything else, some tool or technology as many other, those tools which
> > > > come and go every year.
> > > >
> > > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > 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?
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Delany <de...@gmail.com>.
Hi Tibor,
Another popular principle out there is do one thing well.
The provider principle is already in play with Maven's plugin architecture.
I would much rather have a test plugin purpose built for the test framework
I use.
Its fine until you want to do something a bit extra,
https://github.com/apache/maven-surefire/issues/3146
Without knowing anything about the internals, my perception is that
surefire is hugely complicated with a lot of needless ceremony.
I don't feel that way about any other plugin.
You talk about separation of concerns, but at least from the outside it
seems so many concerns are overlapping.
Configuration, test discovery. Threading is configurable in all three,
junit, surefire, and maven, not to mention the unit under test.
The gold standard is if test frameworks provide their own plugin so there
is clear responsibility for it, and maybe a plugin that shares its namesake
will encourage some buy-in.
If the lineage of developers maintaining the plugin is patchy, what hope is
there for supporting a particular test framework integration,
or looking into deeper issues, or just having some time to respond?
I probably shouldn't talk about contributing code, but I think designing a
plugin that people would want to contribute should be pretty high on the
list of priorities.
Keeping it lean and fit for purpose should keep the number of releases down
too. Its a busy plugin. Probably the busiest?
Delany
On Wed, 8 Oct 2025 at 21:30, Tibor Digana <ti...@apache.org> wrote:
> @Martin Desruisseaux,
>
> >> Even if Maven wanted to be independent of JUnit 5...
> I know Surefire and JUnit5 quite well, no need to tell me, but I was not
> talking about technical things. I am talking about totally different
> topics, especially about good Surefire purpose and design with Providers,
> risk management and the whole globe of users.
> JUnit5 is not a principal shift.
>
> - Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
> 4 + TestNG is intentionally a bad idea.
> The thing happening now goes against the historical continuity because
> previous two developers left ASF.
> - The Surefire originators who designed the architecture had a good
> reasons to introduce Provider API, it is a good design. It separates
> concerns of the plugin from the concerns of test frameworks. Although
> the
> test frameworks have very similar Listeners, they are cohesive with
> Surefire Listener and this enables Maven + plugin to be independent of
> test
> framework implementation across vendors and versions and third party
> policies (pricing, license, SDLC) and this provides us with certain
> freedom
> meaning no coupling (technical coupling and team coupling) between Maven
> plugin and third party frameworks.
>
> >> Keeping direct support of JUnit 3 (as opposed to indirect support
> through JUnit 5 API) has a cost.
> No, this is not true.
> I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
> was stable which means I did not need to touch it for quite a long time.
> This Provider is pretty simple for simple tests, and the positive is that
> the POJO does not require JUnit, this is good for lightweight test
> projects.
>
>
> >> Of course there is a risk that we break something. ... difficult to
> implement.
> It is not difficult to implement. I know Surefire like my shoes.
> My problem is that I left during Covid and the historical continuity with
> new developers was broken, that's my fault, I am honest now. If this did
> not happen then most probably Slawomir would continue straight ahead and
> others maybe too.
>
> Cheers
> Tibor
>
> On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
> <ma...@geomatys.com.invalid> wrote:
>
> > Hello Tibor
> >
> > Even if Maven wanted to be independent of JUnit 5, Maven does not need
> > to invent its own test API. JUnit5 has a separation between API and
> > implementations, so it would be possible to use only the API part if
> > necessary (I don't think that it would be necessary, just mentioning
> > that we have this possibility). Therefore, a full switch to JUnit 5
> > would not necessarily make us fully prisoner of JUnit 5.
> >
> > Keeping direct support of JUnit 3 (as opposed to indirect support
> > through JUnit 5 API) has a cost. For example, I saw requests on this
> > mailing list for testing the different versions of a multi-release JAR
> > file. Currently, any classes in META-INF/versions/* will be ignored at
> > testing time, because Surefire runs the tests with the `*.class` files
> > on the class-path while multi-release works only with JAR files. Last
> > Saturday, I wanted to start looking for the possibility of adding an
> > option for running the tests many times with different
> > `META-INF/versions/*` directories added to the class-path. It was not
> > easy to find my way in the Surefire code, and I rely a lot on the
> > simplification proposed by Romain before to make any other attempt.
> >
> > Of course there is a risk that we break something. But the example given
> > in the previous email (tests as POJO) should be easy to port. The
> > alternative (not removing direct JUnit 3 support) is more like freezing
> > the Surefire plugin: no accidental lost of feature, but also less new
> > features (e.g. easier testing of multi-release projects) because they
> > would be more difficult to implement.
> >
> > Martin
> >
> >
> > Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > > Romain,
> > >
> > > to be honest the JUnit guys always wanted to make their own business
> and
> > > monopoly over the testing phase in Maven, which means using JUnit5
> only,
> > > that's it.
> > >
> > > I have been a JUnit4 developer since cca 2011 or so, and we know each
> > other.
> > > If I say business then I really mean business and not only the word.
> > > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > > still the same competition problems between us, and I say it's about
> the
> > > monopoly, which means who takes the control over these things takes
> full
> > > control over Maven testing and then Maven becomes completely dependent
> on
> > > some test framework which is the risk for Maven.
> > >
> > > This is the main problem but you wouldn't see this unless you have
> spent
> > > years and years developing both parties as I have.
> > >
> > > Making Maven strictly dependent only on JUnit5 is the worst decision
> > > ever, I am telling you!
> > > Btw, experienced Maven guys must know what a strict dependency means
> and
> > > the consequences too.
> > > We are still in the loop for years with deleting something because
> > somebody
> > > has got a crazy idea in the morning, found out github/dev-factory or
> > > anything else, some tool or technology as many other, those tools which
> > > come and go every year.
> > >
> > > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > 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?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Tibor Digana <ti...@apache.org>.
@Martin Desruisseaux,
>> Even if Maven wanted to be independent of JUnit 5...
I know Surefire and JUnit5 quite well, no need to tell me, but I was not
talking about technical things. I am talking about totally different
topics, especially about good Surefire purpose and design with Providers,
risk management and the whole globe of users.
JUnit5 is not a principal shift.
- Supporting only JUnit5 f/w, deleting Provider API, deleting JUnit3 +
4 + TestNG is intentionally a bad idea.
The thing happening now goes against the historical continuity because
previous two developers left ASF.
- The Surefire originators who designed the architecture had a good
reasons to introduce Provider API, it is a good design. It separates
concerns of the plugin from the concerns of test frameworks. Although the
test frameworks have very similar Listeners, they are cohesive with
Surefire Listener and this enables Maven + plugin to be independent of test
framework implementation across vendors and versions and third party
policies (pricing, license, SDLC) and this provides us with certain freedom
meaning no coupling (technical coupling and team coupling) between Maven
plugin and third party frameworks.
>> Keeping direct support of JUnit 3 (as opposed to indirect support
through JUnit 5 API) has a cost.
No, this is not true.
I was a developer of Surefire for many years and JUnit3 + POJO *Provider*
was stable which means I did not need to touch it for quite a long time.
This Provider is pretty simple for simple tests, and the positive is that
the POJO does not require JUnit, this is good for lightweight test projects.
>> Of course there is a risk that we break something. ... difficult to
implement.
It is not difficult to implement. I know Surefire like my shoes.
My problem is that I left during Covid and the historical continuity with
new developers was broken, that's my fault, I am honest now. If this did
not happen then most probably Slawomir would continue straight ahead and
others maybe too.
Cheers
Tibor
On Tue, Oct 7, 2025 at 8:22 PM Martin Desruisseaux
<ma...@geomatys.com.invalid> wrote:
> Hello Tibor
>
> Even if Maven wanted to be independent of JUnit 5, Maven does not need
> to invent its own test API. JUnit5 has a separation between API and
> implementations, so it would be possible to use only the API part if
> necessary (I don't think that it would be necessary, just mentioning
> that we have this possibility). Therefore, a full switch to JUnit 5
> would not necessarily make us fully prisoner of JUnit 5.
>
> Keeping direct support of JUnit 3 (as opposed to indirect support
> through JUnit 5 API) has a cost. For example, I saw requests on this
> mailing list for testing the different versions of a multi-release JAR
> file. Currently, any classes in META-INF/versions/* will be ignored at
> testing time, because Surefire runs the tests with the `*.class` files
> on the class-path while multi-release works only with JAR files. Last
> Saturday, I wanted to start looking for the possibility of adding an
> option for running the tests many times with different
> `META-INF/versions/*` directories added to the class-path. It was not
> easy to find my way in the Surefire code, and I rely a lot on the
> simplification proposed by Romain before to make any other attempt.
>
> Of course there is a risk that we break something. But the example given
> in the previous email (tests as POJO) should be easy to port. The
> alternative (not removing direct JUnit 3 support) is more like freezing
> the Surefire plugin: no accidental lost of feature, but also less new
> features (e.g. easier testing of multi-release projects) because they
> would be more difficult to implement.
>
> Martin
>
>
> Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> > Romain,
> >
> > to be honest the JUnit guys always wanted to make their own business and
> > monopoly over the testing phase in Maven, which means using JUnit5 only,
> > that's it.
> >
> > I have been a JUnit4 developer since cca 2011 or so, and we know each
> other.
> > If I say business then I really mean business and not only the word.
> > Defining report schema and forking mechanism JVMs in JUnit5, these are
> > still the same competition problems between us, and I say it's about the
> > monopoly, which means who takes the control over these things takes full
> > control over Maven testing and then Maven becomes completely dependent on
> > some test framework which is the risk for Maven.
> >
> > This is the main problem but you wouldn't see this unless you have spent
> > years and years developing both parties as I have.
> >
> > Making Maven strictly dependent only on JUnit5 is the worst decision
> > ever, I am telling you!
> > Btw, experienced Maven guys must know what a strict dependency means and
> > the consequences too.
> > We are still in the loop for years with deleting something because
> somebody
> > has got a crazy idea in the morning, found out github/dev-factory or
> > anything else, some tool or technology as many other, those tools which
> > come and go every year.
> >
> > On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > 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?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Martin Desruisseaux <ma...@geomatys.com.INVALID>.
Hello Tibor
Even if Maven wanted to be independent of JUnit 5, Maven does not need
to invent its own test API. JUnit5 has a separation between API and
implementations, so it would be possible to use only the API part if
necessary (I don't think that it would be necessary, just mentioning
that we have this possibility). Therefore, a full switch to JUnit 5
would not necessarily make us fully prisoner of JUnit 5.
Keeping direct support of JUnit 3 (as opposed to indirect support
through JUnit 5 API) has a cost. For example, I saw requests on this
mailing list for testing the different versions of a multi-release JAR
file. Currently, any classes in META-INF/versions/* will be ignored at
testing time, because Surefire runs the tests with the `*.class` files
on the class-path while multi-release works only with JAR files. Last
Saturday, I wanted to start looking for the possibility of adding an
option for running the tests many times with different
`META-INF/versions/*` directories added to the class-path. It was not
easy to find my way in the Surefire code, and I rely a lot on the
simplification proposed by Romain before to make any other attempt.
Of course there is a risk that we break something. But the example given
in the previous email (tests as POJO) should be easy to port. The
alternative (not removing direct JUnit 3 support) is more like freezing
the Surefire plugin: no accidental lost of feature, but also less new
features (e.g. easier testing of multi-release projects) because they
would be more difficult to implement.
Martin
Le 07/10/2025 à 19:16, Tibor Digana a écrit :
> Romain,
>
> to be honest the JUnit guys always wanted to make their own business and
> monopoly over the testing phase in Maven, which means using JUnit5 only,
> that's it.
>
> I have been a JUnit4 developer since cca 2011 or so, and we know each other.
> If I say business then I really mean business and not only the word.
> Defining report schema and forking mechanism JVMs in JUnit5, these are
> still the same competition problems between us, and I say it's about the
> monopoly, which means who takes the control over these things takes full
> control over Maven testing and then Maven becomes completely dependent on
> some test framework which is the risk for Maven.
>
> This is the main problem but you wouldn't see this unless you have spent
> years and years developing both parties as I have.
>
> Making Maven strictly dependent only on JUnit5 is the worst decision
> ever, I am telling you!
> Btw, experienced Maven guys must know what a strict dependency means and
> the consequences too.
> We are still in the loop for years with deleting something because somebody
> has got a crazy idea in the morning, found out github/dev-factory or
> anything else, some tool or technology as many other, those tools which
> come and go every year.
>
> On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <rm...@gmail.com>
> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Tibor Digana <ti...@apache.org>.
Romain,
to be honest the JUnit guys always wanted to make their own business and
monopoly over the testing phase in Maven, which means using JUnit5 only,
that's it.
I have been a JUnit4 developer since cca 2011 or so, and we know each other.
If I say business then I really mean business and not only the word.
Defining report schema and forking mechanism JVMs in JUnit5, these are
still the same competition problems between us, and I say it's about the
monopoly, which means who takes the control over these things takes full
control over Maven testing and then Maven becomes completely dependent on
some test framework which is the risk for Maven.
This is the main problem but you wouldn't see this unless you have spent
years and years developing both parties as I have.
Making Maven strictly dependent only on JUnit5 is the worst decision
ever, I am telling you!
Btw, experienced Maven guys must know what a strict dependency means and
the consequences too.
We are still in the loop for years with deleting something because somebody
has got a crazy idea in the morning, found out github/dev-factory or
anything else, some tool or technology as many other, those tools which
come and go every year.
On Mon, Sep 29, 2025 at 9:09 AM Romain Manni-Bucau <rm...@gmail.com>
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)
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Gary Gregory <ga...@gmail.com>.
Ah! TY for the info, Romain.
Gary
On Mon, Sep 29, 2025 at 8:06 AM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> Hi Gary,
>
> As mentionned JUnit5 engine is a test framework abstraction so you need a
> testng engine like https://github.com/junit-team/testng-engine
>
> 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 lun. 29 sept. 2025 à 13:49, Gary Gregory <ga...@gmail.com> a
> écrit :
>
> > Curious: What about folks who rely on other frameworks like TestNG?
> >
> > Gary
> >
> > On Mon, Sep 29, 2025 at 3:18 AM Romain Manni-Bucau
> > <rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Gary,
As mentionned JUnit5 engine is a test framework abstraction so you need a
testng engine like https://github.com/junit-team/testng-engine
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 lun. 29 sept. 2025 à 13:49, Gary Gregory <ga...@gmail.com> a
écrit :
> Curious: What about folks who rely on other frameworks like TestNG?
>
> Gary
>
> On Mon, Sep 29, 2025 at 3:18 AM Romain Manni-Bucau
> <rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
On Tue, Oct 7, 2025 at 2:48 PM Olivier Lamy <ol...@apache.org> wrote:
> The refactoring branch has already started the idea of simplifying
> things by using only the JUnit Platform engine.
>
[...]
>
> Focusing now on modernising/simplifying the internal parts and
> cleaning legacy code of Surefire/Failsafe is already a big step
> forward.
>
This sounds like the right focus to me. Cleaning up inside, but allowing
users during the maven 3 -> maven 4 transition to "simply upgrade to the
latest version and things keep working" is the right call IMHO. More
disruptive changes will require a proper deprecation/removal cycle and they
can be done for a 4.1 or a 4.2 release.
I disagree that evolving maven and the plugins this way will hold us off a
"maven 5" version in the future. Moving from 4 to 5 will depend on
developer availability and user acceptance. The more users and
organizations adopt maven 4, the higher is the potential of finding
organizations either sponsoring or employing maven developers.
Romain, I get that you see this differently. As a consultant, I would also
push for "changes, changes, new things" because that would be how I earn a
living. As a developer (and maintainer) within an organization, I have
interest in stability and predictability. Dropping two of the absolute core
plugins that have been in maven for 20 (!) years is the opposite of that.
-h
Re: Maven 4 and surefire/failsafe drop?
Posted by Olivier Lamy <ol...@apache.org>.
The refactoring branch has already started the idea of simplifying
things by using only the JUnit Platform engine.
This has already simplified things a lot (~18k lines of code removed
so far including tests).
As you mentioned, there are some abstraction layers to handle test
launching and, more importantly, output and report formatting.
You’d be surprised how easily a tiny change in the XML report format
can break tools like Cucumber, ArchUnit, or CI integrations etc..
(this etc.., is a lot)
Keeping everything backward-compatible is really important. It will
make upgrading much smoother since plugin names (Surefire/Failsafe),
parameters, and report formats will all stay the same.
Switching entirely to the JUnit Platform engine already brings a major
change: it drops support for JUnit versions below 4.12.
That’s already big enough by itself; changing plugin names or
parameters, removing some reporting/output options on top of that
would be too disruptive.
All the abstraction layers for running the JUnit Platform engine,
generating reports, etc., already exist and are familiar to users.
There’s no reason to reinvent them. Just moving to a single test
engine already simplifies maintenance significantly.
I expect even more simplification later, especially around the
abstraction layer that manages communication between the Mojo and the
forked process, once we have only one execution engine done, that’ll
be easier to refine in a second step.
As mentioned in this thread, we can’t just drop existing
Surefire/Failsafe features. Too many tools rely on them, and doing so
would block people from upgrading. Rewriting everything (including the
already existing layer, reporting etc..) from scratch doesn’t make
sense.
Focusing now on modernising/simplifying the internal parts and
cleaning legacy code of Surefire/Failsafe is already a big step
forward.
cheers
Olivier
On Wed, 8 Oct 2025 at 05:14, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le mar. 7 oct. 2025 à 21:02, Henning Schmiedehausen
> <he...@schmiedehausen.org.invalid> a écrit :
>
> > TBH, I am not sure what you are talking about:
> >
> > On Mon, Oct 6, 2025 at 11:18 PM Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> >> Hi Henning,
> >>
> >> Please take the time to read the beginning of the thread, the proposal is
> >> to drop surefire+failsafe since they are superseeded by junit platform, it
> >> literally means supporting all test engines (including junit 3, 4, testng,
> >> spock, cucumber, ....) and common reports (mainly xml in our ecosystem -
> >> but excludes the maven site).
> >>
> >
> > This is from the junit site:
> >
> > [image: Screenshot 2025-10-07 at 11.59.05.png]
> >
> > They literally say "Use failsafe/surefire with junit platform". How is
> > that replacing?
> >
>
> junit platform includes a launcher abstracting any test engine, what is
> missing is a maven plugin wrapping it like
> https://github.com/sormuras/junit-platform-maven-plugin
> as mentionned, my proposal is to just develop that part and delegate the
> wrapper only
>
>
> >
> > -h
> >
> >
> >
> Tibor: this will always be the case when you have a dependency and
> ultimately you can say the same of Java, at some point you have to decide
> what you do own and what you do not.
> I do not think it will be that bad cause ultimately their business will
> rely on maven as well, several big contributors rely on it too (spring for
> ex) and we can still fork if needed which wouldn't be worse than current
> surefire codebase so even if I fully weight your point and in a SWOT it
> would be a risk, I think it is worth doing it, at least for pom with
> modelVersion=4.1.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 7 oct. 2025 à 21:02, Henning Schmiedehausen
<he...@schmiedehausen.org.invalid> a écrit :
> TBH, I am not sure what you are talking about:
>
> On Mon, Oct 6, 2025 at 11:18 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hi Henning,
>>
>> Please take the time to read the beginning of the thread, the proposal is
>> to drop surefire+failsafe since they are superseeded by junit platform, it
>> literally means supporting all test engines (including junit 3, 4, testng,
>> spock, cucumber, ....) and common reports (mainly xml in our ecosystem -
>> but excludes the maven site).
>>
>
> This is from the junit site:
>
> [image: Screenshot 2025-10-07 at 11.59.05.png]
>
> They literally say "Use failsafe/surefire with junit platform". How is
> that replacing?
>
junit platform includes a launcher abstracting any test engine, what is
missing is a maven plugin wrapping it like
https://github.com/sormuras/junit-platform-maven-plugin
as mentionned, my proposal is to just develop that part and delegate the
wrapper only
>
> -h
>
>
>
Tibor: this will always be the case when you have a dependency and
ultimately you can say the same of Java, at some point you have to decide
what you do own and what you do not.
I do not think it will be that bad cause ultimately their business will
rely on maven as well, several big contributors rely on it too (spring for
ex) and we can still fork if needed which wouldn't be worse than current
surefire codebase so even if I fully weight your point and in a SWOT it
would be a risk, I think it is worth doing it, at least for pom with
modelVersion=4.1.0.
Re: Maven 4 and surefire/failsafe drop?
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
TBH, I am not sure what you are talking about:
On Mon, Oct 6, 2025 at 11:18 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi Henning,
>
> Please take the time to read the beginning of the thread, the proposal is
> to drop surefire+failsafe since they are superseeded by junit platform, it
> literally means supporting all test engines (including junit 3, 4, testng,
> spock, cucumber, ....) and common reports (mainly xml in our ecosystem -
> but excludes the maven site).
>
This is from the junit site:
[image: Screenshot 2025-10-07 at 11.59.05.png]
They literally say "Use failsafe/surefire with junit platform". How is that
replacing?
-h
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Henning,
Please take the time to read the beginning of the thread, the proposal is
to drop surefire+failsafe since they are superseeded by junit platform, it
literally means supporting all test engines (including junit 3, 4, testng,
spock, cucumber, ....) and common reports (mainly xml in our ecosystem -
but excludes the maven site).
I also explained that there is already a partial junit extension reading
surefire config which literally enabled me to drop surefire in a project
without changing its configuration.
So think both of your points are solved since more than 5 years at least.
Also I totally disagree with your last point which got proven wrong last
dozen of year: if we do not change now we will never change before maven 5
discussions start, we are not able to break between major releases (which
is not bad, do not get me wrong, but this is also why there is this thread
*now*).
I do not care much if we have the surefire bridge extension, this is a nice
to have but from my experience it will not be a big blocker (surprisingly)
for end users to not have it after a short period of time and we know how
to make surefire active for maven 3 projects and the replacement for maven
4 native projects (based on modelVersion).
So we literally have no blocker to do it, to make it smooth for end users
whatever way fits, and to gain a lot in maintenance since plugin will be
minimal.
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. 7 oct. 2025 à 04:52, Henning Schmiedehausen
<he...@schmiedehausen.org.invalid> a écrit :
> On Mon, Sep 29, 2025 at 6:07 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le lun. 29 sept. 2025 à 14:51, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> > écrit :
> >
> > > I think this thread really starts confusing.
> > >
> > > 1. surefire/failsafe is not part of maven so it can not be "dropped"
> > > from maven 4
> > >
> >
> > You're partially right, let me add what was ambiguous:
> > - do not port surefire/failsafe to maven 4 api
> >
>
> That is not an option. If we start dropping plugins as part of the "3 -> 4
> transition", most serious users will simply not move to 4.
>
> Your options are:
>
> - port everything to Maven 4. Make transitioning from 3 to 4 as painless as
> transitioning from 3.8 to 3.9. Or, better, 3.9.10 to 3.9.11. That will
> give you the most users for Maven 4.
> - do not port everything over. Some users will transition from 3 to 4 and
> eat up the pain of redoing their builds. The majority (and especially
> larger users) will
> - either remain on Maven 3 indefinitely. This is the best case scenario
> - look at the transition cost, ask themselves if they want to keep
> investing in Maven if the community pulls stunts like that or move to
> gradle. The gradle company will post case studies (and tools) to make Maven
> 3 -> gradle transitions simple. You lose your users. Maven 4 becomes
> irrelevant.
>
> Java is a mature ecosystem. Not a growing ecosystem. Unless there is an
> actual user base for Maven 4, there is no point of releasing it. You really
> do not want to split your user base at the most critical moment when you
> need them to trust and follow you across a major version transition
> (something we have not done in 20 (!) years).
>
> Once we managed to get users "over the hump" to Maven 4, we can talk about
> making some more substantial changes. Like in the 4.1 or 4.2 cycle.
>
> -h
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
On Mon, Sep 29, 2025 at 6:07 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le lun. 29 sept. 2025 à 14:51, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
> > I think this thread really starts confusing.
> >
> > 1. surefire/failsafe is not part of maven so it can not be "dropped"
> > from maven 4
> >
>
> You're partially right, let me add what was ambiguous:
> - do not port surefire/failsafe to maven 4 api
>
That is not an option. If we start dropping plugins as part of the "3 -> 4
transition", most serious users will simply not move to 4.
Your options are:
- port everything to Maven 4. Make transitioning from 3 to 4 as painless as
transitioning from 3.8 to 3.9. Or, better, 3.9.10 to 3.9.11. That will
give you the most users for Maven 4.
- do not port everything over. Some users will transition from 3 to 4 and
eat up the pain of redoing their builds. The majority (and especially
larger users) will
- either remain on Maven 3 indefinitely. This is the best case scenario
- look at the transition cost, ask themselves if they want to keep
investing in Maven if the community pulls stunts like that or move to
gradle. The gradle company will post case studies (and tools) to make Maven
3 -> gradle transitions simple. You lose your users. Maven 4 becomes
irrelevant.
Java is a mature ecosystem. Not a growing ecosystem. Unless there is an
actual user base for Maven 4, there is no point of releasing it. You really
do not want to split your user base at the most critical moment when you
need them to trust and follow you across a major version transition
(something we have not done in 20 (!) years).
Once we managed to get users "over the hump" to Maven 4, we can talk about
making some more substantial changes. Like in the 4.1 or 4.2 cycle.
-h
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 29 sept. 2025 à 14:51, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> I think this thread really starts confusing.
>
> 1. surefire/failsafe is not part of maven so it can not be "dropped"
> from maven 4
>
You're partially right, let me add what was ambiguous:
- do not port surefire/failsafe to maven 4 api
- make the related repo maven 3 only and once we'll drop maven 3 we'll move
the repos to read-only state
> 2. instead I assume the proposal is to replace the default mojo bind to
> the test phase in the jar lifecycle(!) to something else
>
Yep
> 3. This than might result in retiring failsafe/surefire on the long run
>
+1
>
> Apart from that I already mentioned in the the last "round" for the same
> reason it might be better to have no default binding for the test-phase
> then everyone can choose what fits best with a simple plugin entry in
> the (parent) pom (and no this won't make maven a new ant).
>
I already mentionned that we should probably not fall in that until:
1. we assume there is no default binding for everything - including
compiler => just use ant
OR
2. we keep a default for most common steps of the build (package can be the
immediate need since it is the most "common" command) and test is there. We
stay (I do strongly hope) with conventions over configurations so we must
have something but I would be happy to consume junit plugin instead of
doing our own since it overlaps a lot now.
>
> Am 29.09.25 um 13:42 schrieb Gary Gregory:
> > Curious: What about folks who rely on other frameworks like TestNG?
> >
> > Gary
> >
> > On Mon, Sep 29, 2025 at 3:18 AM Romain Manni-Bucau
> > <rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
I think this thread really starts confusing.
1. surefire/failsafe is not part of maven so it can not be "dropped"
from maven 4
2. instead I assume the proposal is to replace the default mojo bind to
the test phase in the jar lifecycle(!) to something else
3. This than might result in retiring failsafe/surefire on the long run
Apart from that I already mentioned in the the last "round" for the same
reason it might be better to have no default binding for the test-phase
then everyone can choose what fits best with a simple plugin entry in
the (parent) pom (and no this won't make maven a new ant).
Am 29.09.25 um 13:42 schrieb Gary Gregory:
> Curious: What about folks who rely on other frameworks like TestNG?
>
> Gary
>
> On Mon, Sep 29, 2025 at 3:18 AM Romain Manni-Bucau
> <rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Gary Gregory <ga...@gmail.com>.
Curious: What about folks who rely on other frameworks like TestNG?
Gary
On Mon, Sep 29, 2025 at 3:18 AM Romain Manni-Bucau
<rm...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Let me repeat it another time: my proposal is not to drop junit 3, 4,
testng, spock and friends support, my proposal is to move to junit engine
abstraction instead of having our own so there is no JUnit5 migration plan
in my proposal.
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 lun. 29 sept. 2025 à 15:32, Gary Gregory <ga...@gmail.com> a
écrit :
> I can confirm that have at lesst 1 private project (corporate day job) and
> at least 1 Apache project that are "stuck" on JUnit 3 and 4. Migrating to
> JUnit 5 is not free, especially if you rely on custom rules.
>
> Gary
>
>
> On Mon, Sep 29, 2025, 08:56 Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
>
> > I am very skeptical that this is feasible. I still encounter new
> > projects with JUnit *3*. There are a phenomenal number of projects in
> > active development that depend on JUnit 3 and 4. JUnit 3, 4, and 5 are
> > very different frameworks and migrating from one to the next is not
> > trivial and usually not important or a wise use of developer time. Any
> > action that's predicated on everyone moving to JUnit 5 seems like a
> > non-starter.
> >
> > On Mon, Sep 29, 2025 at 7:09 AM Romain Manni-Bucau
> > <rm...@gmail.com> 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)
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Gary Gregory <ga...@gmail.com>.
I can confirm that have at lesst 1 private project (corporate day job) and
at least 1 Apache project that are "stuck" on JUnit 3 and 4. Migrating to
JUnit 5 is not free, especially if you rely on custom rules.
Gary
On Mon, Sep 29, 2025, 08:56 Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> I am very skeptical that this is feasible. I still encounter new
> projects with JUnit *3*. There are a phenomenal number of projects in
> active development that depend on JUnit 3 and 4. JUnit 3, 4, and 5 are
> very different frameworks and migrating from one to the next is not
> trivial and usually not important or a wise use of developer time. Any
> action that's predicated on everyone moving to JUnit 5 seems like a
> non-starter.
>
> On Mon, Sep 29, 2025 at 7:09 AM Romain Manni-Bucau
> <rm...@gmail.com> 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)
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
I'd like to second that. Java (and Maven) are part of a very mature
ecosystem and there are organizations that have invested in "older"
frameworks such as JUnit 4 or TestNG (or Maven).
Is there value to have a newer test runner that can be dropped in instead
of surefire/failsafe? Yes. But we can not just abandon the vast amount on
existing integrations and code that is using these.
I am fine with declaring "we will not actively add new features to
surefire/failsafe but we may consider contributions/PRs. New work for test
execution will be focused on "<new plugin> and will only support <some test
framework>" and let users choose.
-h
On Mon, Sep 29, 2025 at 5:47 AM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> I am very skeptical that this is feasible. I still encounter new
> projects with JUnit *3*. There are a phenomenal number of projects in
> active development that depend on JUnit 3 and 4. JUnit 3, 4, and 5 are
> very different frameworks and migrating from one to the next is not
> trivial and usually not important or a wise use of developer time. Any
> action that's predicated on everyone moving to JUnit 5 seems like a
> non-starter.
>
> On Mon, Sep 29, 2025 at 7:09 AM Romain Manni-Bucau
> <rm...@gmail.com> 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)
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
I am very skeptical that this is feasible. I still encounter new
projects with JUnit *3*. There are a phenomenal number of projects in
active development that depend on JUnit 3 and 4. JUnit 3, 4, and 5 are
very different frameworks and migrating from one to the next is not
trivial and usually not important or a wise use of developer time. Any
action that's predicated on everyone moving to JUnit 5 seems like a
non-starter.
On Mon, Sep 29, 2025 at 7:09 AM Romain Manni-Bucau
<rm...@gmail.com> 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)
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 5 févr. 2026 à 12:59, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Thu, Feb 5, 2026 at 6:48 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
>
> > TestNG main consumer was EE suite due to the xml configuration, then most
> > moved to arquillian and JUnit 4 and now they (+ their sibling
> microprofile
> > projects) moved to JUnit5 stack.
>
> Java EE was one consumer of TestNG, hardly the only one. Presto also
> uses it with Maven, last I checked, and there are many others.
>
Migration is pretty trivial if you review it (speaking of presto but others
are generally as simple) and once again it is not really the point since
dropping testng support from surefire means we do support testng (no typo
in the sentence).
Point is more than there is no more demand for TestNG support.
To rephrase it, for me questions are:
1. is testng alive -> yes but really maintenance mode in you review the
commits == we must enable to run it somehow but at low cost if possible
2. does surefire need any code to support testng -> no, so why do we have
it these days except legacy we can drop for maven 4?
Side is: the fact surefire does add an abstraction on another abstraction
now also literally blocks end users to use what surefire does abstract - as
always, an abstraction is a good way to drop features users can want to
use, since technically it can't be justified in our context I think we can
drop it.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Feb 5, 2026 at 6:48 AM Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> TestNG main consumer was EE suite due to the xml configuration, then most
> moved to arquillian and JUnit 4 and now they (+ their sibling microprofile
> projects) moved to JUnit5 stack.
Java EE was one consumer of TestNG, hardly the only one. Presto also
uses it with Maven, last I checked, and there are many others.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 5 févr. 2026 à 12:09, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Mon, Sep 29, 2025 at 3:09 AM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> >
>
> > On another side, testng and junit4 are slowly getting abandonned - even
> EE
> > TCK started to move.
> >
>
> First I've heard that TestNG is being abandoned. The GitHub repo and
> web asite look active. Can you say more? I'm not a particular TestNG
> fan, but I do regularly encounter it in major open source projects.
>
TestNG main consumer was EE suite due to the xml configuration, then most
moved to arquillian and JUnit 4 and now they (+ their sibling microprofile
projects) moved to JUnit5 stack.
Not saying you will not find JUnit4 or TestNG anywhere but clearly the move
is that these are in maintenance mode - partly thanks surefire dependency
scanning, so my conclusion is that:
* These are really in maintenance mode so no need to maintain anything crazy
* JUnit5 abstraction does cover it so if you do support JUnit 5 then you do
support TestNG and JUnit 4
>
> I do know that the rumors of JUnit 4's death are greatly exaggerated.
>
Please don't mix death and abandon - which means still maintained when
pressure is big enough.
Both means we don't need to promote them as first class citizen - same
impact for us - but it is slightly different in the meaning.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4 and surefire/failsafe drop?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Mon, Sep 29, 2025 at 3:09 AM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> On another side, testng and junit4 are slowly getting abandonned - even EE
> TCK started to move.
>
First I've heard that TestNG is being abandoned. The GitHub repo and
web asite look active. Can you say more? I'm not a particular TestNG
fan, but I do regularly encounter it in major open source projects.
I do know that the rumors of JUnit 4's death are greatly exaggerated.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4 and surefire/failsafe drop?
Posted by Martin Desruisseaux <ma...@geomatys.com.INVALID>.
I do not know yet the internal of Maven Surefire Plugin, but my
understanding of Romain's explanation is that since JUnit 5, the
abstraction layer provided by the Maven Surefire Plugin overlaps with an
abstraction layer already provided by JUnit 5, and there is no reason to
keep both layers. If that understanding is correct, then indeed I would
appreciate the simplification proposed by Romain, especially since it
would make easier future evolution of the Surefire Plugin. For example,
I have in mind adding an option for re-running the same tests many times
with classpath that reflect the different releases in a multi-releases
project. It would probably be easier after Romain's proposal.
Martin
Le 29/09/2025 à 09:07, Romain Manni-Bucau a écrit :
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org