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] > >
