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
