That's nice, so I reconsider my vote as -0 : only a fix until plugin version are required by maven 2.1, but I had prefered the equivalent enforcer code to be integrated to core and WARN (optionally FAIL) when no plugin version is specified. This would be - more educational - a good preparation for new 2.1 requirements
Proposal to set plugins version fix unstable behavior but does not educate users. About "I don't want a huge XML", maybe we should consider updating Modello to use attributes as an alternative to verbose XML elements. We could use namespaces to avoid conflict with 2.0 schema ... but that should be dicussed in another thread ! Nico. 2008/2/10, Brian E. Fox <[EMAIL PROTECTED]>: > > Yes, I had to walk the poms in the rule to see if the version was > specified anywhere. (the model in project always has versions filled in, > even if they aren't actually specified in the poms.) The code stops > walking up the pom tree when there is no parent specified and it doesn't > look in the super pom. The net result is that if you haven't locked down > your versions and you use the requirePluginVersions rule, then it will > fail just like it does today. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of nicolas de loof > Sent: Saturday, February 09, 2008 11:05 PM > To: Maven Developers List; [EMAIL PROTECTED] > Subject: Re: Plugin Versions in the Super pom > > Could the enforcer plugin still warn about missing plugins version if > they > are set in the super POM ? > > Nico > > > 2008/2/10, Ralph Goers <[EMAIL PROTECTED]>: > > > > In my world I require a reproduceable build. Typically, that means a > > specific release would have to be built using a specific version of > > Maven. Any attempt to build it at a later time would need to still use > > that release. This isn't just because of default versions of plugins > > but because the behavior of Maven itself might have changed. > > > > Now, while I think it is great to have default versions of plugins, > when > > push comes to shove I won't really care. Just like I will use my own > > managed dependency specifications to control dependency versions I > would > > also recommend explicitly controlling the plugin versions used. I'm > not > > a big fan of letting Maven dynamically pick versions of anything as it > > leads to a build which can't be reliably recreated. > > > > So if this proposal means that each version of Maven hard-wires > default > > versions of plugins - but that those plugin versions can be overridden > > then I definitely agree that that is the correct way to go. > > > > Ralph > > > > nicolas de loof wrote: > > > I have to change my vote to -1 : > > > > > > Current maven behavior introduces some issues when plugin version is > not > > > set. Many users got errors with this and learned to use version. > > > > > > Having maven super-POM set plugin version will make the build depend > on > > > maven version used. > > > > > > Simple scenario : > > > > > > I create a project with maven 2.0.9, wich introduces superPOM > > > with versionned plugins. My build is reproductible even when new > plugins > > are > > > released. This DOESN't learn me best-practices about plugins > > versionning. > > > > > > Latter I come back to this project for maintenance with maven > 2.0.11, > > that I > > > expect to be backward compatible. As not beeing a hacker I don't > even > > know > > > what version of maven I'm using, simply run some eclipse integration > > (maybe > > > we will have some one day or the other) > > > > > > ... and the project gets broken as 2.0.11 superPOM doesn't set the > same > > > plugins ! > > > > > > > > > I got such scenario in REAL-WORLD projects using maven1 : > maintenance > > > developers (maven newbees) had errors when building the project ... > > because > > > maven 1.1 was installed as default on the developer environment, and > the > > > project used maven 1.0.2 with some uncompatible plugins. > > > > > > > > > > --------------------------------------------------------------------- > > 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] > >
