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]
