commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [all] Preparing for commons-parent pom release
Date Thu, 25 Feb 2010 00:32:53 GMT
On Wed, Feb 24, 2010 at 11:42 PM, sebb <sebbaz@gmail.com> wrote:
> On 24/02/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>> On Wed, Feb 24, 2010 at 4:40 PM, sebb <sebbaz@gmail.com> wrote:
>>  > On 24/02/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>>  >> On Wed, Feb 24, 2010 at 1:07 AM, sebb <sebbaz@gmail.com> wrote:
>>  >>  > On 24/02/2010, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>>  >>  >> I'd like to do a release of the commons-parent pom - primarily
to
>>  >>  >>  upgrade to the latest commons-build-plugin 1.2 release.
>>  >>  >>
>>  >>  >>  I have also upgraded the plugin versions and changed the
"rc" &
>>  >>  >>  "release" profiles to now only produce the javadocs and not
the whole
>>  >>  >>  site (this resolves a problem for multi-module components).
>>  >>  >>
>>  >>  >>  Are there any other changes or feedback before calling a
vote on this?
>>  >>  >
>>  >>  > I think the default maven.compile.source|target entries should
be
>>  >>  > removed from the POM.
>>  >>  >
>>  >>  > Seems to me that projects should have to define these, and not
rely on
>>  >>  > the default.
>>  >>
>>  >>
>>  >> I disagree with this because the whole point of the commons-parent
>>  >>  pom.xml is to reduce the amount of dulicate configuration in component
>>  >>  projects and I see no benefit in forcing components to define
>>  >>  unnecessary properties when the default suits them.
>>  >
>>  > But the compilation source and target are specific to each project,
>>  > just like inceptionYear.
>>
>>
>> As I said it reduces duplication of configuration - no difference from
>>  inherintance in java.
>>
>
> It does not reduce duplication in the long run, as each project that
> upgrades from the minimum of 1.3 will need to define the properties.
> It can only reduce duplication for the very few projects that will
> never change their minimum version from 1.3.
>
>>  > Unlike other properties, such as plugin versions, the source and
>>  > target versions can never be updated in the parent pom. If it is
>>  > updated, that all projects that are currently relying on the default
>>  > will have to be updated to override the parent pom. At which point the
>>  > parent pom properties become useless anyway.
>>
>>
>> The parent-pom is versioned and released - we can update those values
>>  at any time. Obviously if we did change the values we would have to
>>  make each component had the correct value configured either through
>>  the parent or overriden in its pom before it was moved to the new
>>  version parent.
>
> Exactly.
>
> So every project that does not currently want to use 1.3 must override
> the properties.

Yes, and those that are still on 1.3 don't have to.

> If the parent pom properties were ever to change from 1.3, then those
> projects that currently rely on the default must define the
> properties, at which point the parent pom properties are not being
> used by any projects.

So worst case secario they're redundant which is not a big deal OR we
decide to change the default.

>>  > It's also tedious trying to find the JVM requirements if one has to
>>  > look in both the project pom and the parent pom.
>>
>>
>> Tedious is something people do repetitively - I'm sure once people see
>>  whats in the parent they don't have to continually go back and keep
>>  checking.
>>
>
> But if the value in the parent POM can change, and multiple parent
> poms are in use, then rechecking *is* needed.

Agreed, if and when they ever change. I imagine that *might* only
happen once we no longer have a component with a minimum of 1.3. If it
ever does I'm sure it will be discussed first and someone will ensure
that everything is correctly setup. But thats some theoretical
red-herring IMO.

These default have IMO worked well and I haven't seen any good
argument yet for removing them and so I'm against it.

Niall

>>  >>  I also think this is a non-issue. We have a good history over the past
>>  >>  few years of making sure components are compatible with the JDK
>>  >>  version they target and I don't believe theres a single example of a
>>  >>  release that had these properties incorrectly set.
>>  >>  Also we did have this discussion before:
>>  >>
>>  >>  http://markmail.org/message/sc2d7efxscz6n3sz
>>  >>
>>  >
>>  > I know, and I still disagree.
>>
>>
>> Me too :)
>>
>>
>>  Niall
>>
>>
>>  >>  Niall
>>  >>
>>  >>
>>  >>  >>  Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message