commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: commons-parent-7 discussion
Date Sat, 12 Jan 2008 13:38:01 GMT
simon wrote:
> On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
>> On Jan 11, 2008 11:29 PM, Dennis Lundberg <> wrote:
>>> Jochen Wiedmann wrote:
>>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <>
>>>>> 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.

Running 'mvn help:effective-pom' is a great help if you are ever in 
doubt what the pom will look like after inheritance has been applied.

> 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.

Plugins, like any piece of software, go through changes. That means that 
you should try out a new version to make sure it works for your build. 
To minimize this testing it is a good thing to standardize which version 
to use.

If a component needs another version, than the one specified in the 
parent pom, it can just declare another version in the components own 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:
> For additional commands, e-mail:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message