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