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 Wed, 24 Feb 2010 22:44:28 GMT
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.

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

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

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