On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote: > On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > Jochen Wiedmann wrote: > > > On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > > >> Theres also the issue of specifying the "version" of the > > >> remote-resources-plugin - which in previous discussions people > > >> objected to. Please Note this is not configuring commons-parent to > > >> *use* that plugin - but just to specify the version number *if* a > > >> component does use it. I don't mind it going in and it has no impact > > >> unless components use it. Does anyone still have a problem with doing > > >> this? Also are there any other changes people think should be made > > >> before trying to release commons-parent-7? > > > > > > I have no particular problem with it, apart from the fact that I find > > > it pointless. > > > > > > If there is some code that actually uses the plugin, then that makes > > > sense. This code might be contained in some profile, in other words, > > > not used unless explicitly requested. But just to fix a version > > > number? What for? > > > > The reason is to have reproducible builds. It makes sure that, no matter > > who is building component A, the end result will always be the same. > > This is not quite the case - reproducability is the reason for > specifying the version, but not the reason for specifying the version > in the parent pom. The reason for specifying version numbers in the > parent is to not have to go through endless component poms updating > version numbers - maintain the version numbers in the parent and just > keep the commons-parent version up-to-date in the components.
It seems to me that specifying version numbers in parent poms is in fact exactly the *wrong* thing to do, and *particularly* for plugins. Instead, a version number should always be specified instead by the pom that uses the plugin. For a start, this is much easier to audit: any time a plugin is declared in a pom, we can say that there *must* be a version value in the declaration. Easy. But with "inherited" versions, we see poms with missing version tags, and have to trace through the ancestry to see what versions are used. Yes, things like the maven-enforcer-plugin can do checks on this (once its new version is released) but obvious is still better than unclear-in-source-but-automatically-validated. And why would we ever care that some modules use version X of a plugin, and some use version Y? If a module declares it needs version X, and builds correctly with version X, then it seems *bad* to me to force an unnecessary change via inheriting new settings from a parent pom. So in short, I think that we should not define mrrp in the commons parent, and just let modules that *use* it define the version they want. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
