On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote: > On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: > > For me, I am completely aware that I want to lock *everything* down > > (including plugins) to have reproducible builds. So marketing, > > advertising, pleading with us, educating us is not the issue.
> The code in the enforcer plugin can actually extract the versions that > were used as part of a build so we could turn this into something > people could use. John has also been working on a lifecycle plugin > which displays the information about the lifecycle which means we > could extract the information from that too and make a descriptor. So > we can test different combinations of plugins as they are released and > give those combinations to users in some controlled way. 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. 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. Isn't that part of what the enforcer plugin actually does? If so, then why not make that a default plugin in maven 2.0.9, ie bind it to an appropriate phase by default? It would be also nice for maven to have the ability to dump the versions of stuff it uses for any particular build, then allow later runs of maven to accept that dump-file as input to set the versions. That's a quick-fix for people who find 2.0.9 reporting errors on their builds due to incomplete dependency versioning. I've personally never encountered a situation where one version of a plugin would not work with some other version of a different plugin. What I have found difficult is determining whether things *have* all been locked down or whether something has been missed. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
