Le mar. 5 août 2025 à 11:38, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy, > > So many wrong informations: > - super POM does not contains plugin versions > > https://github.com/apache/maven/blob/master/impl/maven-impl/src/main/resources/org/apache/maven/model/pom-4.0.0.xml > - maven does not have a notion of "external" (vs "internal"?) plugins > - lifecycle is the one defining plugin versions > > https://github.com/apache/maven/blob/master/impl/maven-core/src/main/java/org/apache/maven/lifecycle/providers/packaging/AbstractLifecycleMappingProvider.java > - plugins not on lifecycle are NOT "locked" even with lifecycle, this > means they are being resolved to "latest" (ie m-assembly-p), and if > there is a release between now and tomorrow, your unlocked build will > pick up latest (and every time it happens) > > This is all just so wrong and proven to be wrong. > > And in fact, I'd go step further: > - why is maven carrying lifecycles? Lifecycles should be in some > extension (with version of it only in Maven, resolved on first run) > - this would allow us to completely detach it from Maven Core > Agreed, there was a plan to externalize the lifecycles afaik. Not sure where we stand right now... but it would be worth continuing the effort imho. > > > T > > On Tue, Aug 5, 2025 at 11:11 AM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > This is the point, super pom is hardcoded and already there so as soon > you > > want to be deterministic you do lock maven version and transitively > default > > plugins. > > > > Side note: external plugins should be locked and are almost by design, > this > > is fine, what is broken is the behavior for default lifecycles only. > > > > Also agree security changed...but locking doesn't help at all there since > > the version is locked even when implicit, just tied to maven. > > > > So there is no pro to lock default plugins technically, only cons. > > > > Romain Manni-Bucau > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > > Blog <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | LinkedIn > > <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > Le mar. 5 août 2025 à 09:07, Matthias Bünger <mbuen...@apache.org> a > écrit : > > > > > Morning, > > > > > > I'm totally with Tamás. We should, I would even say: we have to, keep > > > version locking a thing. Times, developer experience and security > > > concerns have changed a lot over the past 20 years and droping locking > > > is a bad and big step back from my point of view. > > > > > > We also have to keep in mind that the majority of users and most of the > > > devs who are the "build managers/POM maintainers" at their teams don't > > > know the enforcer plugin. And I keep my point that such important > things > > > should be default by Maven nowaday and not a not-so-known best > > > practices. This said the validation message should a) make clear why > > > version locking is important and b) it would be great if it also offers > > > a command to automatically fix it. I could imagine that the Maven > > > Upgrade Tool could help (Maven 4 users) a lot here. > > > > > > We could also think about adding core plugins to a plugin management > > > section in Maven Super POM - however this only helps a bit in terms of > > > non-core-plugins. > > > > > > Matthias > > > > > > Am 05.08.2025 um 00:00 schrieb Tamás Cservenák: > > > > So to recap: you want to drop a "best practice" (in effect since > 2009) as > > > > it is "too much typing" (adding plugin mgmt), and make solution > instead > > > to > > > > use enforcer and make given project buildable by only one single > maven > > > > version. Am I correct? > > > > > > > > Silly. > > > > > > > > On Mon, Aug 4, 2025, 22:48 Romain Manni-Bucau <rmannibu...@gmail.com > > > > > wrote: > > > > > > > >> Le lun. 4 août 2025 à 22:44, Tamás Cservenák <ta...@cservenak.net> > a > > > >> écrit : > > > >> > > > >>> Howdy, > > > >>> > > > >>> locking the plugin versions is considered (and communicated) as > "best > > > >>> practice" since 2009 (since Maven 3 appeared). > > > >>> > > > >> And the warning just makes it obvious everyone uses it ;) > > > >> > > > >> > > > >>> Otherwise, you get plugin versions that are coming from the > lifecycle > > > >>> in the _used_ maven version, and if you use one version, and > somebody > > > >>> else some other version, plugins versions are mixed up. Moreover, > we > > > >>> still have "fairly recent" Maven versions that are running 2.x > plugins > > > >>> (!) > > > >>> > > > >> The same best practises likely references the fact that if you want > to > > > >> protect yourself from that feature you use maven enforcer and > actually > > > lock > > > >> maven. > > > >> This is why I explained in my original post that version locking > doesn't > > > >> solve the problem you described way better than me, only locking > > > versions > > > >> including maven does and once done the problem disappears. > > > >> > > > >> > > > >>> So you want to undo the best practice that was communicated since > 2009? > > > >>> > > > >> When it is not adopted and wrong why not? > > > >> > > > >> > > > >>> Thanks > > > >>> T > > > >>> > > > >>> On Mon, Aug 4, 2025 at 10:39 PM Romain Manni-Bucau > > > >>> <rmannibu...@gmail.com> wrote: > > > >>>> Hi all, > > > >>>> > > > >>>> We discussed multiple times the plugin version locking but it is > an > > > >> issue > > > >>>> for the ones involved in the default lifecycle since now when you > > > >> create > > > >>> a > > > >>>> new project you need 50 lines to lock versions (from my window the > > > >>>> convention over configuration became a configuration over > > > >> anything)...and > > > >>>> then you locked versions so upgrading maven is harder than it was > by > > > >> the > > > >>>> past. > > > >>>> > > > >>>> There is a debate between: > > > >>>> > > > >>>> 1 we need to lock version to get the build deterministic > > > >>>> 2 we shouldn't lock versions and stay aligned on the defaults > within > > > >>> maven > > > >>>> 1 is quite wrong since it also implicitly assume you do not > change the > > > >>>> maven version (otherwise it just doesnt work for the same reason > you > > > >> want > > > >>>> to lock plugin versions) but 2 is not 100% perfect since it can > hide > > > >> the > > > >>>> fact you do use another version. > > > >>>> > > > >>>> However we are lucky and have enforcer plugin which does solves > it. > > > >>>> > > > >>>> So I wonder if we should revert the version locking warning when > pom > > > is > > > >>>> without any build section for default plugins. > > > >>>> > > > >>>> I know a custom extensions can somehow replace a super pom and > kind of > > > >>>> solve it but you still need to define it which is still undesired > to > > > >>> have a > > > >>>> proper default "convention" setup IMHO. > > > >>>> > > > >>>> Romain Manni-Bucau > > > >>>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > >>>> <https://dotnetbirdie.github.io/> | Blog < > > > >> https://rmannibucau.github.io/> > > > >>> | Old > > > >>>> Blog <http://rmannibucau.wordpress.com> | Github > > > >>>> <https://github.com/rmannibucau> | LinkedIn > > > >>>> <https://www.linkedin.com/in/rmannibucau> | Book > > > >>>> < > > > >> > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > >>> > --------------------------------------------------------------------- > > > >>> 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
