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 )
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.
I also don't said to drop the _test phase_ but to drop surefire as a
_default binding_ for that phase in jar packaging.
Am 08.09.25 um 12:54 schrieb Romain Manni-Bucau:
> Le lun. 8 sept. 2025 à 12:09, Christoph Läubrich <m...@laeubi-soft.de> 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 <m...@laeubi-soft.de
>>> :
>>>>
>>>> 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: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
