No, I want to make the best practice accurate and at the same time restore maven origins to be able to work without having to start to configure a bunch of things you often do not even know (not sure everyone knows maven clean is a plugin for ex). If you do not lock maven version it is pointless to lock plugin versions, just think about it so the best practise was wrong - and luckily we realize it now cause nobody notice this switch between maven 2 and 3 ;).
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 à 00:01, Tamás Cservenák <ta...@cservenak.net> a écrit : > 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 > > > > > > > > >
