I think the idea of specifying versions in the "super pom" is
pointless. Stability for a given release of maven is not particularly
useful when many users are using different versions of maven to build
something.
I think it's common sense that the proposed lock down in the super POM is
not the final solution and was not intended as such. Reproducible builds
require the user himself to lock the plugin versions in his own (corporate)
POM, nobody else can do this.
The changes to the super POM are all about improving (not solving) the
current situation for Maven 2.0.x. If we can agree on the assumption that
there are less different versions of Maven in use than local repositories
existent among the developers, the additions in the super POM help to
improve build reproducibility.
It would be much more useful for maven 2.0.9 to simply *warn* when a
plugin is found without a version. That's better than trying to
"advertise" best practice via the maven website. Better yet, have it
fail the build unless some kind of "override" option is present on the
command-line.
For the sake of backward-compatibility within the 2.0.x development line,
one surely would not want to break the build here.
What I have found difficult is determining whether things *have* all
been locked down or whether something has been missed.
You could run
mvn clean deploy site-deploy -U
and grep for "checking for updates" in the log output.
Regards,
Benjamin Bentmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
