Le lun. 8 sept. 2025 à 16:04, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit :
> Le lun. 8 sept. 2025 à 14:53, Christoph Läubrich <m...@laeubi-soft.de> a > écrit : > > > 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. > > > > We agree this is only true when you do not speak about the plugin but the > phase - surefire is designed to satisfy everybody (as well as junit5 > platform now), this is why it is so much pluggable. > > > > > > 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. > > > > True, guess default was not central but building locally. > Central is more a particular case with moving constraints, not sure we > should make it in defaults but can be interesting to debate it and > ultimately solve it since it would enable to have a smoother path and maybe > open the door to built-in profiles. > > > > > > 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. > > > > Was true when we didnt have local staging of artifacts, now it is less true > and we just need to run surefire after the packaging IMHO which would make > both kind of test converging which is what the industry does since 10+ > years IMHO. > This is already implemented in Maven 4. The new concurrent builder uses the tree-based phase definitions, where the test phase is not bound to run between the compile and package phase, but rather between inside the verify phases, independently of the package phase. For compatibility, when the phase tree is flattened to a list, so that the usual single-threaded or multi-threaded builders can use those, we keep the usual order. I also want to point out that mixins can play a role to help define things that are orthogonal to the plain hierarchy. It's now in master and would allow defining what a "spring app" or "quarkus app" is, and bind some plugins by default. Guillaume > > Also keep in mind that if you drop failsafe you get it back by binding > surefire in a custom (priority based) phase so you actually do not loose > anything and keep you will to be declarative. > > So sounds like you explained well we can merge both and how to match all > cases to me. > > > > > > Am 08.09.25 um 14:20 schrieb Romain Manni-Bucau: > > > Le lun. 8 sept. 2025 à 13:39, Christoph Läubrich <m...@laeubi-soft.de> > 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 < > > 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 > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- ------------------------ Guillaume Nodet
