I agree that the ability to lock down a build is important for release management, but part of the beauty of Maven is the ability to concisely declare a build and at the same time benefit from incremental improvements in various components of it.
Inhouse, we use a buildinfo-plugin (from "Better Builds ..") to capture all the build information and this data is packaged up with each built artifact. So it is always possible to recreate a build exactly. This gives us the ability to assimilate new plugin versions without needing to modify POMs or parent POMs. I'd hate to lose that. So I would rather see this requirement fulfilled by a mechanism that can be switched on or off as needed like the enforcer-plugin. William -----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, 2 September 2007 1:26 AM To: Maven Developers List Subject: [***POSSIBLE SPAM***] - Re: [PROPOSAL] Plugin packs and concrete versioning - Email has different SMTP TO: and MIME TO: fields in the email addresses On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote: > Le samedi 1 septembre 2007, Brian E. Fox a écrit : >> I think we can do this just by generating a sample pluginManagement >> snippet on the site somewhere. I don't think anything fancy is >> needed, simply providing the snipet so someone can copy and paste >> will be more than sufficient. Having it generated with the current >> latest release would then make it a good starting point as most >> people would want the latest by default and would only resort to >> reverting if they hit a problem with a particular plugin. > +1 > > IMHO, a link to it should be added to http://maven.apache.org/ > plugins/, because it's the same information in another format. > Plugins groups (or packs) are already organized here, and can be > represented in the pluginManagement snippet as XML comments > > WDYT? > Yes, that's all that's necessary. As noted previously we already have, even for 2.0.x users, a way with the enforcer plugin to help greatly stabilize builds and if we started publishing these snippets tomorrow we'll go another big step. How we make this more seamless can come in time but it can all come in the form of external tooling to find the snippets. We could even fake mixins in this particular case by making people use a certain comment element and we could insert this snippet. When mixins are supported we can transition over to using that without much problem. I don't think the idea of a plugin pack buys us anything configuration management wise as we 1) loose visibility of plugin versioning which is important in a corporate build, 2) don't need anything special in the model to represent this, it just makes things more complicated. > Hervé > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
