Thank you for thoughtful answer. My post was purely about the stock plugins, not any plugin. Also my post is purely for those scenarios where Maven Wrapper is used.
I'll be sharpening my point (I hope it will hold): I think mentioning stock plugins versions in <pluginManagement> for a project that uses Maven Wrapper is actually DETRIMENTAL. It has no upside in terms of reproducibility (it's unchanged level) and makes upgrading the Maven version more cumbersome. It also hides the developer's intentions. Hear me out. Stock plugins are special: They have a default version implied by the Maven version. (ref: for v3.9.9 it would be this list: https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html). Now, we can say that the versions of the stock plugins implied by the Maven version are merely suggestions by the Maven developers to the Maven users. But they are more than that: They are GOOD suggestions. Example: If use of Maven 3.9 _requires_ an update of the jar-plugin then I'm sure it is reflected in those defaults. When Maven X.Y.Z is released it has undergone IT with those plugins. So yes, someone in the core team has made a conscious decision that for this particular Maven version then this set of stock plugin versions are a good and reasonable choice. It stumbling close to "curated". :-) Frankly, my concern is that (at least for me) those plugin versions would become stale in my POM. Would I remember to re-evaluate them when I update my Maven version? Would I know that I would need to update say the jar-plugin because I update Maven version from 3.8 to 3.9? or else mysterious things would happen. No, I wouldn't. In reality, if I _had_ locked them down in <pluginManagement> then whenever I updated the Maven version I would try to figure out what the new set of the default stock plugin versions are, apply that in my <pluginManagement> in my POM, and then re-test build to see if it worked. Quite a lot of work. Bottom line: I would need a strategy for keeping them up-to-date and following the Maven version is the least worst strategy I can come up with. Better than letting them go stale. An analogy with Spring Boot is justified I think: When I see a Spring Boot project that has locked down (explicitly) a core dependency (say SLF4J) then I'm immediately assuming that it is because that that version must _not_ follow the Spring Boot version. The developer had some intention behind it. Some good reason why it cannot be the default. Developer is implicitly trying to tell me: "Look here: I had to use something non-default for this dependency". Perhaps she even made a note as to why. Comparing that with Maven POM: Let's say I'm digging into an existing project that uses the Maven Wrapper. I always start looking at the POM. I would notice all those <pluginManagement> locked versions and start to wonder for each of those plugins: "Gee, you have already locked the Maven version so why this particular version lock for this plugin?". Is it because you truly need exactly vX.Y.Z and the default version cannot be used? ... or (more likely) you added it because you got an unwarranted warning from Maven and thought adding that section would make your build more reproducible? I bet it is almost always the latter 🙂. But as a reader of the POM I wouldn't know. It is a mental cost when reading the POM and when keeping it up-to-date. Not explicitly specifying a version of the stock plugins indeed provides information. It means: I haven't identified a specific need other than the default. Specifying it explicitly actually makes the situation worse because I wouldn't know why the developer has done it. At least for Spring Boot I would know the developer has only done so because he couldn't live with the default. (that's the convention in that world: don't do anything if you are okay with the defaults. Only specify exceptions) I think part of the debate is due to history. In the past - before the Maven Wrapper - people would get different results on different developer workstations or different build hosts .. because Maven was "supplied" by the host. Things would mysteriously change without any commits. But now I see the Maven Wrapper as omnipresent in projects and a range of those problems therefore no longer exist. I claim that 80% of projects are plain vanilla projects that use only the stock plugins. Furthermore, I claim that 99% of those are happy to use the default versions of the stock plugins that goes along with the Maven version the project has decided to use. The majority of projects have no identified need for a specific version of the stock plugins. Maven takes heat for a POM which is seen as very verbose. In this case - when following the advice in the warning and when using the Maven Wrapper - the Maven build recipe becomes not only verbose but also repetitive. Creating additional tools to help the user maintain the "<pluginManagement>" section is just more mental load. Maven already has a steep enough learning curve. Joe, the average developer, has no feeling for what version of say the jar-plugin he wants to use. He just wants to build, package and deploy his project. So why force him to have an opinion? Why not say: "if you don't know and if you've already locked the Maven version, then we'll decide for you". I bet Joe will be happy. 🙂 Admittedly, not sure I've thought about corner cases, such as the development of Maven plugins or extensions. Here the use of the Enforcer to pin-down a version range for Maven itself may be justified. But that's not the standard case (Joe's plain vanilla project). I'm merely concerned that the POM's complexity keeps rising .. without justified benefit. (Luckily Maven 4 is a good step towards POM simplicity overall. Thank you !!) I've edged it a bit here. But we should indeed be mindful that not everyone spends their day in Maven land. For the majority, crafting the POM and keeping it up-to-date takes 0.2% of their time. And that is okay. My 2c. /Lars PS: in the interest of constructiveness I thought this was actually just a case of Bill-of-Material to be applied. Some mechanism to say that this build opts-in on Maven's stock plugin versions. However, as far as I know Maven's BOM mechanism doesn't work for plugin management. On 06/02/2025 10.19, Tamás Cservenák wrote: > Howdy, > > This is IMHO not a good idea. Locking down plugins by locking down > Maven.... is too implicit for my taste. > > For start, we provide a set of tools to help "locking down" > (https://issues.apache.org/jira/browse/MNG-8408) > but also maintain them (versions plugin or toolbox:plugin-versions and alike). > > Maven is not a "curated set of plugins" we usually "just update" when > we feel so. It is the user who should maintain the versions. > > Finally, one can still enforce a Maven version usable with build, this > is usually used to set "minimum version" (open range) but one can use > a very narrow closed range as well.. > > Thanks > T > > On Mon, Feb 3, 2025 at 2:07 PM Lars Bruun-Hansen <lbr...@apache.org> wrote: >> -- DISCUSSION -- >> >> MNG-6562 introduced the warning : >> >> "Version not locked for default bindings plugins [maven-clean-plugin, >> maven-resources-plugin, maven-compiler-plugin, maven-surefire-plugin, >> maven-jar-plugin, maven-install-plugin], you should define versions in >> pluginManagement section of your pom.xml or parent." >> >> The warning was added before the Maven Wrapper became popular. For a >> project that uses Maven Wrapper the warning does not make sense to me: >> those plugin versions are indeed de-facto locked. Right? The build is >> already reproducible and will always yield the same result regardless on >> which platform it is executed. (We must assume that users are aware that >> IF a project contains a Maven Wrapper then it is because you are >> supposed to use it! (i.e. execute 'mvnw' , not 'mvn')). >> >> The warning leads to the user rushing to extend/complicate his POM while >> this is unnecessary when using the wrapper. I believe the "lock" between >> a specific Maven version (e.g. v3.9.2) and its default plugin versions >> is something that to the user should be equally good as adding that long >> list of dependencies to the POM. I get it that we want to educate users >> that Maven is "a collection of plugins" but in reality users see the >> Maven version as a CURATED set of plugin dependencies. Which indeed it >> is, right? >> >> My suggestion is to not print this warning if the build is being >> executed by the Maven Wrapper. I don't know if this possible, i.e. >> detecting that mvn is being executed by the wrapper? >> >> Spitballing : Also, the POM could have some kind of setting to signal to >> Maven that it MUST be executed via the wrapper. Or at least that is is >> INTENDED to be executed using the wrapper. Then Maven could execute a >> warning(or fail) if that is not the case. >> >> >> Alternatively: extend the warning message: >> "If you have de-facto locked the Maven version, for example by using the >> Maven Wrapper, then you can ignore this warning." >> >> >> WDYT? >> >> >> >> /Lars >> >> >> PS : As it may be obvious, I'm a great fan of the Wrapper and I believe >> it should be advocated more and projects should have a very good reason >> NOT to use it. Luckily, many project initializers add it by default >> (e.g. Spring Initializr) but the Maven Project itself doesn't make that >> much out of it. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
