What if we enhance the super poms for 4.1.0 model to include managed plugins with versions ? The plugins would be locked *and* easily modifiable. Or, better (as this could depend on the maven version which is running), define a mixin that we could release whenever a core lifecycle plugin is updated. That would work with dependabot and other tools, as soon as they are updated to support mixins.
I.e. trying to find a solution to fix the ease of use, without breaking the underlying feature... Le mar. 5 août 2025 à 11:13, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > 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 > > > > > -- ------------------------ Guillaume Nodet
