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