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 2008/01/11 10:57:13 UTC
commons-parent-7 discussion
I just made some more changes to commons-parent:
http://svn.apache.org/viewvc?view=rev&revision=611126
This includes the "hack" to put the NOTICE/LICENSE files in the
javadoc jar (which Dennis was -1 to, but three people agreed). See
http://tinyurl.com/2zueu5 for all changes since commons-parent-6.
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?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> I just made some more changes to commons-parent:
> http://svn.apache.org/viewvc?view=rev&revision=611126
>
> This includes the "hack" to put the NOTICE/LICENSE files in the
> javadoc jar (which Dennis was -1 to, but three people agreed). See
> http://tinyurl.com/2zueu5 for all changes since commons-parent-6.
>
> 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?
Just release it as it is now, without all thing related to
maven-remote-resources-plugin.
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/11/08, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> OK revised changes since commons-parent-6 is here: http://tinyurl.com/2v5lnh
>
> (I left in the javadoc plugin as that takes part in the build too?)
>
<snap/>
Don't know, but thanks for pushing this along (other changed look good to me).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 11, 2008 10:50 AM, Niall Pemberton <ni...@gmail.com> wrote:
> On Jan 11, 2008 10:47 AM, Jörg Schaible
> <Jo...@elsag-solutions.com> wrote:
> > Hi Niall,
> >
> >
> > Niall Pemberton wrote:
> > > I just made some more changes to commons-parent:
> > > http://svn.apache.org/viewvc?view=rev&revision=611126
> > >
> > > This includes the "hack" to put the NOTICE/LICENSE files in the
> > > javadoc jar (which Dennis was -1 to, but three people agreed). See
> > > http://tinyurl.com/2zueu5 for all changes since commons-parent-6.
> > >
> > > 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?
> >
> > You have to set the versions of the plugins used in the reporting section directly. They are not affected by the version set in the pluginManagement section (unfortunatelly). The pluginManagement entries will only influence the plugins of the build section.
>
> Doh! OK thanks for the info - I'll correct it.
OK revised changes since commons-parent-6 is here: http://tinyurl.com/2v5lnh
(I left in the javadoc plugin as that takes part in the build too?)
Niall
> Niall
>
>
> > - Jörg
> >
> > BTW: Just in case someone does not believe this: Set the version of the javadoc plugin to 2.2 and reference it without version once in the build and the reporting section. Then use M205 to build the site. It will fail, since it tries to use for the report the newer maven-javadoc-plugin 2.3 which needs a newer Maven version.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 11, 2008 10:47 AM, Jörg Schaible
<Jo...@elsag-solutions.com> wrote:
> Hi Niall,
>
>
> Niall Pemberton wrote:
> > I just made some more changes to commons-parent:
> > http://svn.apache.org/viewvc?view=rev&revision=611126
> >
> > This includes the "hack" to put the NOTICE/LICENSE files in the
> > javadoc jar (which Dennis was -1 to, but three people agreed). See
> > http://tinyurl.com/2zueu5 for all changes since commons-parent-6.
> >
> > 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?
>
> You have to set the versions of the plugins used in the reporting section directly. They are not affected by the version set in the pluginManagement section (unfortunatelly). The pluginManagement entries will only influence the plugins of the build section.
Doh! OK thanks for the info - I'll correct it.
Niall
> - Jörg
>
> BTW: Just in case someone does not believe this: Set the version of the javadoc plugin to 2.2 and reference it without version once in the build and the reporting section. Then use M205 to build the site. It will fail, since it tries to use for the report the newer maven-javadoc-plugin 2.3 which needs a newer Maven version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: commons-parent-7 discussion
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Hi Niall,
Niall Pemberton wrote:
> I just made some more changes to commons-parent:
> http://svn.apache.org/viewvc?view=rev&revision=611126
>
> This includes the "hack" to put the NOTICE/LICENSE files in the
> javadoc jar (which Dennis was -1 to, but three people agreed). See
> http://tinyurl.com/2zueu5 for all changes since commons-parent-6.
>
> 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?
You have to set the versions of the plugins used in the reporting section directly. They are not affected by the version set in the pluginManagement section (unfortunatelly). The pluginManagement entries will only influence the plugins of the build section.
- Jörg
BTW: Just in case someone does not believe this: Set the version of the javadoc plugin to 2.2 and reference it without version once in the build and the reporting section. Then use M205 to build the site. It will fail, since it tries to use for the report the newer maven-javadoc-plugin 2.3 which needs a newer Maven version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/11/08, Dennis Lundberg <de...@apache.org> wrote:
> Rahul Akolkar wrote:
> > On 1/11/08, Niall Pemberton <ni...@gmail.com> wrote:
> >> On Jan 11, 2008 10:06 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
> >>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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?
> >> Because Dennis wants it and if it causes no issues, then its one less
> >> thing to disagree on.
> >>
> > <snip/>
> >
> > But its one more thing to maintain (and update versions, and trigger a
> > pom release etc. -- as an aside, the number of Maven related releases
> > may have exceeded component releases in the recent past).
>
> We don't have to use the latest versions if we don't want to. If we are
> happy with version 1.0 we can stick with that for ever and ever, without
> the need to update commons-parent.
>
> The number of Maven related release will decrease over time, once we
> have settled in on how we want to do all things Maven.
>
<snip/>
Yes, thats the theory.
> > Also, it
> > isn't adding much value given recent discussions and the current state
> > of its implementation, metadata etc. IMO.
>
> See my comment to Jochen.
>
<snap/>
I don't buy the reproducibility argument in this context.
> > I don't think of this as having more or less things to disagree on,
> > but we've had a long discussion and the reservations expressed by more
> > than one of us have been well articulated therein, IMO.
>
> There has been misunderstandings in said discussions regarding this. I
> suggest that you read what Niall wrote in the first mail of this thread
> once more, as he summed up the implications of the change nicely.
>
<snip/>
I responded to his direct question (or tried to, apparently) about any
downsides to configure mrrp version in the parent (at this point in
time).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
Rahul Akolkar wrote:
> On 1/11/08, Niall Pemberton <ni...@gmail.com> wrote:
>> On Jan 11, 2008 10:06 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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?
>> Because Dennis wants it and if it causes no issues, then its one less
>> thing to disagree on.
>>
> <snip/>
>
> But its one more thing to maintain (and update versions, and trigger a
> pom release etc. -- as an aside, the number of Maven related releases
> may have exceeded component releases in the recent past).
We don't have to use the latest versions if we don't want to. If we are
happy with version 1.0 we can stick with that for ever and ever, without
the need to update commons-parent.
The number of Maven related release will decrease over time, once we
have settled in on how we want to do all things Maven.
> Also, it
> isn't adding much value given recent discussions and the current state
> of its implementation, metadata etc. IMO.
See my comment to Jochen.
> I don't think of this as having more or less things to disagree on,
> but we've had a long discussion and the reservations expressed by more
> than one of us have been well articulated therein, IMO.
There has been misunderstandings in said discussions regarding this. I
suggest that you read what Niall wrote in the first mail of this thread
once more, as he summed up the implications of the change nicely.
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/11/08, Niall Pemberton <ni...@gmail.com> wrote:
> On Jan 11, 2008 10:06 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
> > On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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?
>
> Because Dennis wants it and if it causes no issues, then its one less
> thing to disagree on.
>
<snip/>
But its one more thing to maintain (and update versions, and trigger a
pom release etc. -- as an aside, the number of Maven related releases
may have exceeded component releases in the recent past). Also, it
isn't adding much value given recent discussions and the current state
of its implementation, metadata etc. IMO.
I don't think of this as having more or less things to disagree on,
but we've had a long discussion and the reservations expressed by more
than one of us have been well articulated therein, IMO.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 11, 2008 10:06 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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?
Because Dennis wants it and if it causes no issues, then its one less
thing to disagree on.
Niall
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 12, 2008 2:33 PM, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > 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.
In contrary, it isn't.
The version should (at least IMO) be specified by the pom, which
requests the plugin, because that pom known what features it wants or
doesn't want. Of course, if a child pom specifies additional code or
configuration, it must be able to change the version number. What
nonsense would it be to deal with the compiler plugin in the parent
pom (as we do it now), which is otherwise completely ignored by the
child poms (apart from specifying a Java version for source and
target, as it is now) and force the childs to be aware of the
differences between the various versions of the compiler plugin?
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Jochen Wiedmann wrote:
>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
Good point.
>
> Niall
>
>> Specifying versions for all plugins is considered a best practice. This
>> has been discussed a lot on the Maven mailing-lists. I can give you some
>> pointers if you like.
>>
>>> Jochen
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Phil Steitz <ph...@gmail.com>.
On Jan 12, 2008 3:37 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/12/08, Jochen Wiedmann <jo...@gmail.com> wrote:
> > On Jan 12, 2008 3:25 PM, simon <si...@chello.at> wrote:
> >
> > > I don't see the point of that at all. Commons-xxx projects do not exist
> > > for the purposes of testing maven plugins. If commons-xxx can build
> > > successfully with version N of a plugin, then there is no reason to ever
> > > use any other version of the plugin.
> > >
> > > Well, one minor case is with report plugins, so that the reports
> > > generated by related modules look similar. But maven can't help with
> > > that anyway, as it doesn't provide <pluginManagement>.
> >
> > Well that boils down to the question, whether we should have a
> > commons-parent or at least whether we should have only one. For
> > example, we might as well have a pom with reports only.
> >
> > I am personally quite happy about it because I have the feeling that
> > it helps me. That's the reason why this discussion engages me. Others
> > (including you?) don't seem to keen on using its features.
> >
> > I have no particular feelings if a subproject decides to use a
> > particular version of the commons-parent pom or not to use it at all.
> > OTOH, I'd ask that those who want to use it should be left more alone.
> >
> <snip/>
>
> Also note:
> * I believe RMs are left alone to choose ant, m1 or m2, and details
> that make sense therein
+1 - that has always been our way and as long as your next point is
upheld, it just comes down to what is easiest for the individual RM.
> * If you have an expectation to be left alone in things such as the
> generation and content of L&N files, that expectation is unrealistic
> (in other words, there are some things that interest / should interest
> everyone and for better or worse, we're consensus driven)
+1 there too. We have some minimum requirements that we argue about
from time to time, but it is important for us to maintain consensus on
what they are and when we play the RM role, we adhere to them.
Call me an optimist, but I think that thanks to the m2 experts among
us, we are getting close to having a simple, easy-to-use build
environment for m2. We had that for some time with m1 and it helped
make cutting commons releases less of a "black art." The /releasing
pages document what is still a fairly arcane process using m1 that
will become easier with m2. We will get that documented, these long
threads will die, and we will get back to talking about (our own ;)
code. That's my theory and I'm sticking to it :)
Phil
>
> -Rahul
>
>
> ---------------------------------------------------------------------
> 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: commons-parent-7 discussion
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/12/08, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Jan 12, 2008 3:25 PM, simon <si...@chello.at> wrote:
>
> > I don't see the point of that at all. Commons-xxx projects do not exist
> > for the purposes of testing maven plugins. If commons-xxx can build
> > successfully with version N of a plugin, then there is no reason to ever
> > use any other version of the plugin.
> >
> > Well, one minor case is with report plugins, so that the reports
> > generated by related modules look similar. But maven can't help with
> > that anyway, as it doesn't provide <pluginManagement>.
>
> Well that boils down to the question, whether we should have a
> commons-parent or at least whether we should have only one. For
> example, we might as well have a pom with reports only.
>
> I am personally quite happy about it because I have the feeling that
> it helps me. That's the reason why this discussion engages me. Others
> (including you?) don't seem to keen on using its features.
>
> I have no particular feelings if a subproject decides to use a
> particular version of the commons-parent pom or not to use it at all.
> OTOH, I'd ask that those who want to use it should be left more alone.
>
<snip/>
Also note:
* I believe RMs are left alone to choose ant, m1 or m2, and details
that make sense therein
* If you have an expectation to be left alone in things such as the
generation and content of L&N files, that expectation is unrealistic
(in other words, there are some things that interest / should interest
everyone and for better or worse, we're consensus driven)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 12, 2008 3:25 PM, simon <si...@chello.at> wrote:
> I don't see the point of that at all. Commons-xxx projects do not exist
> for the purposes of testing maven plugins. If commons-xxx can build
> successfully with version N of a plugin, then there is no reason to ever
> use any other version of the plugin.
>
> Well, one minor case is with report plugins, so that the reports
> generated by related modules look similar. But maven can't help with
> that anyway, as it doesn't provide <pluginManagement>.
Well that boils down to the question, whether we should have a
commons-parent or at least whether we should have only one. For
example, we might as well have a pom with reports only.
I am personally quite happy about it because I have the feeling that
it helps me. That's the reason why this discussion engages me. Others
(including you?) don't seem to keen on using its features.
I have no particular feelings if a subproject decides to use a
particular version of the commons-parent pom or not to use it at all.
OTOH, I'd ask that those who want to use it should be left more alone.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
simon wrote:
> On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
>> simon wrote:
>>> On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
>>>> On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> Jochen Wiedmann wrote:
>>>>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
>> 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.
>
> I don't see the point of that at all. Commons-xxx projects do not exist
> for the purposes of testing maven plugins. If commons-xxx can build
> successfully with version N of a plugin, then there is no reason to ever
> use any other version of the plugin.
Oh come on!!!
When did I ever say that "commons projects exist for the purposes of
testing maven plugins"? You are reading my comments like the devil reads
the bible.
Regarding versions, did you even read the thread???
See:
http://markmail.org/message/ui6bhy2akjckkdco
I have been saying *exactly* that.
This is it for me. Over and out!
> Well, one minor case is with report plugins, so that the reports
> generated by related modules look similar. But maven can't help with
> that anyway, as it doesn't provide <pluginManagement>.
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by simon <si...@chello.at>.
On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
> simon wrote:
> > On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
> >> On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>> Jochen Wiedmann wrote:
> >>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
>
> 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.
I don't see the point of that at all. Commons-xxx projects do not exist
for the purposes of testing maven plugins. If commons-xxx can build
successfully with version N of a plugin, then there is no reason to ever
use any other version of the plugin.
Well, one minor case is with report plugins, so that the reports
generated by related modules look similar. But maven can't help with
that anyway, as it doesn't provide <pluginManagement>.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
simon wrote:
> On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
>> On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> Jochen Wiedmann wrote:
>>>> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by simon <si...@chello.at>.
On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
> On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
> > Jochen Wiedmann wrote:
> > > On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Niall Pemberton <ni...@gmail.com>.
On Jan 11, 2008 11:29 PM, Dennis Lundberg <de...@apache.org> wrote:
> Jochen Wiedmann wrote:
> > On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
Niall
> Specifying versions for all plugins is considered a best practice. This
> has been discussed a lot on the Maven mailing-lists. I can give you some
> pointers if you like.
>
> > Jochen
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
Jochen Wiedmann wrote:
> On Jan 12, 2008 12:29 AM, Dennis Lundberg <de...@apache.org> wrote:
>
>> 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.
>>
>> Specifying versions for all plugins is considered a best practice. This
>> has been discussed a lot on the Maven mailing-lists. I can give you some
>> pointers if you like.
>
> Dennis, you don't understand my point. I do not oppose version numbers
> in general. I am simply asking to restrict version numbers to those
> plugins, which are actually used in a pom file. As soon as the
> commons-parent pom *is* using the mrr plugin, then I'm all in favour
> for adding a version number.
>
> You don't ask to add a version number for the war plugin, just because
> projects *could* use the war plugin, do you?
Yes I would. If one or more of our components was using the war plugin,
then I would ask for the version of the war plugin to be added to the
pluginManagement element in commons-parent.
>
> Jochen
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 12, 2008 12:29 AM, Dennis Lundberg <de...@apache.org> wrote:
> 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.
>
> Specifying versions for all plugins is considered a best practice. This
> has been discussed a lot on the Maven mailing-lists. I can give you some
> pointers if you like.
Dennis, you don't understand my point. I do not oppose version numbers
in general. I am simply asking to restrict version numbers to those
plugins, which are actually used in a pom file. As soon as the
commons-parent pom *is* using the mrr plugin, then I'm all in favour
for adding a version number.
You don't ask to add a version number for the war plugin, just because
projects *could* use the war plugin, do you?
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Dennis Lundberg <de...@apache.org>.
Jochen Wiedmann wrote:
> On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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.
Specifying versions for all plugins is considered a best practice. This
has been discussed a lot on the Maven mailing-lists. I can give you some
pointers if you like.
> Jochen
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-parent-7 discussion
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Jan 11, 2008 10:57 AM, Niall Pemberton <ni...@gmail.com> 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?
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org