You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2010/02/24 01:29:37 UTC
[all] Preparing for commons-parent pom release
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?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by sebb <se...@gmail.com>.
On 25/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 11:42 PM, sebb <se...@gmail.com> wrote:
> > On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> On Wed, Feb 24, 2010 at 4:40 PM, sebb <se...@gmail.com> wrote:
> >> > On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> >> On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
> >> >> > On 24/02/2010, Niall Pemberton <ni...@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
Worst case scenario is a project relies on the default incorrectly.
> decide to change the default.
If the default is ever changed, then any projects that still rely on
the default will need to override the properties when they link to the
new parent pom - unless by chance they happen to be changing to the
same new 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.
My concern is that it is not as safe as insisting that each project
define the properties itself. Each project is forced to consider - and
document - the minimum JVM version it supports.
This is like inceptionYear - it really does not make sense for that to
be defaulted (and thankfully it is not).
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 24, 2010 at 11:42 PM, sebb <se...@gmail.com> wrote:
> On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> On Wed, Feb 24, 2010 at 4:40 PM, sebb <se...@gmail.com> wrote:
>> > On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >> On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
>> >> > On 24/02/2010, Niall Pemberton <ni...@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
Re: [all] Preparing for commons-parent pom release
Posted by sebb <se...@gmail.com>.
On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 4:40 PM, sebb <se...@gmail.com> wrote:
> > On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
> >> > On 24/02/2010, Niall Pemberton <ni...@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.
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.
>
> > 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.
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 24, 2010 at 4:40 PM, sebb <se...@gmail.com> wrote:
> On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
>> > On 24/02/2010, Niall Pemberton <ni...@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
Re: [all] Preparing for commons-parent pom release
Posted by sebb <se...@gmail.com>.
On 24/02/2010, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
> > On 24/02/2010, Niall Pemberton <ni...@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.
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.
It's also tedious trying to find the JVM requirements if one has to
look in both the project pom and the parent pom.
> 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.
> Niall
>
>
> >> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 24, 2010 at 1:07 AM, sebb <se...@gmail.com> wrote:
> On 24/02/2010, Niall Pemberton <ni...@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.
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
Niall
>> Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by sebb <se...@gmail.com>.
On 24/02/2010, Niall Pemberton <ni...@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.
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Feb 26, 2010 at 7:50 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Niall Pemberton wrote at Freitag, 26. Februar 2010 02:30:
>
>> In case anyone isn't following the OSGi POOL-60 thread, I have changed
>> the budle plugin config and upgraded the bundle plugin version:
>>
>> http://markmail.org/message/4n5ycmqzw5zdjqhh
>> http://svn.apache.org/viewvc?view=revision&revision=916523
>
> Can you use ${project.version} instead of ${pom.version}. IIRC the pom.*
> variables are deprecated and will probably no longer work with Maven 3.x.
Thanks, fixed!
http://svn.apache.org/viewvc?view=revision&revision=916637
Niall
> - Jörg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Jörg Schaible <jo...@gmx.de>.
Niall Pemberton wrote at Freitag, 26. Februar 2010 02:30:
> In case anyone isn't following the OSGi POOL-60 thread, I have changed
> the budle plugin config and upgraded the bundle plugin version:
>
> http://markmail.org/message/4n5ycmqzw5zdjqhh
> http://svn.apache.org/viewvc?view=revision&revision=916523
Can you use ${project.version} instead of ${pom.version}. IIRC the pom.*
variables are deprecated and will probably no longer work with Maven 3.x.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Preparing for commons-parent pom release
Posted by Niall Pemberton <ni...@gmail.com>.
In case anyone isn't following the OSGi POOL-60 thread, I have changed
the budle plugin config and upgraded the bundle plugin version:
http://markmail.org/message/4n5ycmqzw5zdjqhh
http://svn.apache.org/viewvc?view=revision&revision=916523
Niall
On Wed, Feb 24, 2010 at 12:29 AM, Niall Pemberton
<ni...@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?
>
> Niall
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org