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