But that's the point, there is no choice that will satisfy *all* (or
even *most*) cases well, but it is well known to maven user to enable
additional plugins for their need.
Thinking further, why Is not javadoc plugin part of the default
life-cycle? Why not maven.source-plugin? Both are requirements for
central what we can clearly say is a convention as well to have
source+javadoc.
Anyways I just wanted to mention this to give a hint to think "outside
the box" not because I really think maven will ever change ;-)
So alone the discussion here where some want it *Replaced* other want it
*Additionally*, then we have the problem with decide what is an IT what
a unit test (why should i not be able to execute unit test with
surefire?!?) for me proves that there is no one-fits-all convention but
maybe a *convincing* to have it enabled. e.g. how many CIs are run with
ignored testfailures because they want the CI to pick up failing test
instead of fail the package what failsafe also solves with having an
extra verify step and so on.
Am 08.09.25 um 14:20 schrieb Romain Manni-Bucau:
Le lun. 8 sept. 2025 à 13:39, Christoph Läubrich <[email protected]> a
écrit :
Honestly look at any maven project and you will see that "convention
over configuration" is a nice idea but practically never
used/applicable... (I won't reference to the ASF parent pom here :-P )
this is partly true only, write a pom, write a gav, run mvn package build
and it works most of the time assuming you do not expect more than what you
should (if you build with java 17 do not expect java 21 code to compile by
default is what I mean).
so this is still a thing and even in asf parent pom, most of the
configuration is within convention and I do not think we do redeclare
phases which is what your proposal ends up to.
Also I often see the recommendation to "lock" default plugin versions
(e.g. because default ones are outdated and to be independent of maven
version) so what really buys us then not also adding one execution for
surefire/failsafe/whatever anyways if wanted.
This is still a pending bug of the comin v4.0.0 which should be fixed
before the final, this is not really acceptable to create a pom then run a
tool - will not recreate the huge thread about it there but this is not a
point IMHO since it already shouts in maven's head if we let it go.
I also don't said to drop the _test phase_ but to drop surefire as a
_default binding_ for that phase in jar packaging.
Kind of the same for me since you will still have to do something to have
your tests working.
Do not get me wrong, I think surefire is way too legacy to be the best
default choice - think
https://github.com/sormuras/junit-platform-maven-plugin is way more
relevant for the future - but it works well, is adopted and is there and if
we switch it we should still have something to fill the gap by default.
Doesn't mean we cant enable to replace it as you want byt we need a default
and today it is surefire.
Am 08.09.25 um 12:54 schrieb Romain Manni-Bucau:
> Le lun. 8 sept. 2025 à 12:09, Christoph Läubrich <[email protected]>
a
> écrit :
>
>>
>> e.g. Tycho has own surefire/failsafe-variants:
>>
>>
>>
https://tycho.eclipseprojects.io/doc/latest/tycho-surefire-plugin/plugin-info.html
>>
>> bnd-plugin uses junit under the cover but not surefire nor failsafe:
>>
>>
>>
https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-testing-maven-plugin
>>
>> Groovy at least requires special configuration with surefire, so one
has
>> to "enable" it to scan for non java files.
>>
>> Pax Exam allows running tests in container (e.g. J2EE):
>>
>> https://github.com/ops4j/org.ops4j.pax.exam
>>
>> Maven-plugins even have maven-invoker:
>>
>> https://maven.apache.org/plugins/maven-invoker-plugin/
>>
>> ... so there is a wide range of other things that might want to be "the
>> default" so instead of choosing e.g surefire/failsafe as the default
>> (what is only one way) it would be better to ask explicitly configure
>> how to test instead of having it in the default life-cycle. With JUnit
>> Platform one might even ask why surefire at all (that serves a similar
>> purpose).
>>
>
> Doesn't it defeat maven convention over configuration spirit?
> If so maven is just a "pipeline" and if we go (i hope not but if so)
then
> we should assume it and also drop initialize, compile, etc... phase to
> become just ant with another DSL.
>
> Personally I think it makes sense to have a default test phase.
> Already today failsafe is useless cause you can explicitly define it
using
> surefire and in maven 4 we have clean and robust phase ordinals
helping to
> do that (post package becomes easy whereas it was not when
integration-test
> was a thing).
>
> Now the question if we keep a single phase for test is when? After the
> packaging doesn't sound crazy but will not be backward compat in terms
of
> classpath so some build will fail but I think it can make sense on
the long
> run since it will enable to write whatever test you want, moving the
> filtering/their execution to filters/categories/includes/excludes on the
> run command if you want to split.
>
>
>>
>> Then a user can choose e.g. if only surefire, only failsafe, maybe both
>> or something completely different should be used.
>>
>>
>> Am 08.09.25 um 11:55 schrieb Mirko Friedenhagen:
>>> Do you mean surefire or junit? What other plugin do you use to start
>> tests?
>>> Mit freundlichen Grüßen
>>> Mirko Friedenhagen
>>> —
>>> Sent from my mobile
>>>
>>>> Am 08.09.2025 um 08:08 schrieb Christoph Läubrich <
[email protected]
>>> :
>>>>
>>>> I would go the other way round and remove the surefire plugin
instead
>> as there are even more testing framework providers and not all
can/want use
>> surefire.
>>>>
>>>> So for me less is more and disabling it in case it is not wanted is
>> always a bit cumbersome. Then everyone can simply configure in their
parent
>> pom whats wanted by default.
>>>>
>>>>> Am 05.09.25 um 07:56 schrieb Rüdiger:
>>>>> Hiho!
>>>>> I was wondering, what you all think about adding the failsafe plugin
>> to the super pom of maven 4. I often work with young teams, and it's
>> difficult to explain, why the surefire plugin works out of the box,
but the
>> failsafe plugin does not... and of course, it's a nuisance to have
to add
>> it to every project.
>>>>> Maybe unit tests used to be more important than integration tests in
>> the past, but my perception is that this is changing: ITs become
more and
>> more the primary way of testing, while unit tests become more
optional and
>> focus on more complex algorithms.
>>>>> Kind regards
>>>>> Rüdiger
>>>>>
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
