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/02/27 14:05:53 UTC
[VOTE] Release commons-parent 8
Hi,
I'd like to release version 8 of the commons-parent pom - the changes
since the last release are:
- re-order mailing archives
- configure the maven-bundle-plugin (for OSGi)
- configure the commons-build-plugin (for OSGi)
- maven-install-plugin 2.1 --> 2.2
- maven-surefire-plugin 2.3 --> 2.4.2
- specify encoding for the javadoc and compiler plugins
- specify a "phase" for the javadoc and sources plugins in the
rc/release profiles
- configure the install plugin to create checksums in the rc/release profiles
A full diff of the pom.xml can be found at this address:
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=631209&r2=611431&diff_format=h
The version number in the pom will be updated automatically during the
release process.
[ ] +1
[ ] =0
[ ] -1
Vote is open for 72 hours
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [VOTE] Release commons-parent 8
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
+1
Niall Pemberton wrote:
> Hi,
>
> I'd like to release version 8 of the commons-parent pom - the changes
> since the last release are:
> - re-order mailing archives
> - configure the maven-bundle-plugin (for OSGi)
> - configure the commons-build-plugin (for OSGi)
> - maven-install-plugin 2.1 --> 2.2
> - maven-surefire-plugin 2.3 --> 2.4.2
> - specify encoding for the javadoc and compiler plugins
> - specify a "phase" for the javadoc and sources plugins in the
> rc/release profiles
> - configure the install plugin to create checksums in the
> rc/release profiles
>
> A full diff of the pom.xml can be found at this address:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/tru
> nk/pom.xml?r1=631209&r2=611431&diff_format=h
>
> The version number in the pom will be updated automatically during
> the release process.
>
> [ ] +1
> [ ] =0
> [ ] -1
>
> Vote is open for 72 hours
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by James Carman <ja...@carmanconsulting.com>.
On 2/28/08, Niall Pemberton <ni...@gmail.com> wrote:
> OK seems like theres a bit of an impasse on this since we disagree.
> Currently there are two +1 votes - if you feel strongly I suggest you
> vote -1 on this release, otherwise if it gets three +1 votes and
> reaches +72hrs I'll release it.
>
>
> Niall
Well, you've got my +1 to release commons-parent-8.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
OK seems like theres a bit of an impasse on this since we disagree.
Currently there are two +1 votes - if you feel strongly I suggest you
vote -1 on this release, otherwise if it gets three +1 votes and
reaches +72hrs I'll release it.
Niall
On Wed, Feb 27, 2008 at 4:15 PM, sebb <se...@gmail.com> wrote:
> On 27/02/2008, simon.kitching@chello.at <si...@chello.at> wrote:
> > Niall Pemberton schrieb:
> >
> > > On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
> > >
> > >> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > >> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> > >> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > >> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > >> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > >> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > > <inceptionYear>2001</inceptionYear>
> > >> > > > > > > <maven.compile.source>1.3</maven.compile.source>
> > >> > > > > > > <maven.compile.target>1.3</maven.compile.target>
> > >> > > > > >
> > >> > > > > >
> > >> >
> > >> >
> >
> > >> > The whole idea of commons-parent is that we don't have to explicitly
> > >> > configure everything in the component pom's - you set it in the parent
> > >> > and override only if necessary. So while it may only be three lines in
> > >> > EACH component pom - I'm against adopting what you say as a principle.
> > >> >
> > >>
> > >> I am not suggesting that all the defaults in the parent POM should be removed.
> > >>
> > >> What I am saying is that it *is necessary* for projects to override
> > >> *these items*.
> > >>
> > >
> > > Well I don't agree with you - its a bad principle to set requiring
> > > duplicatiion for any items and IMO *its not necessary* for *these
> > > items*
> >
> >
> > Guys, you need to drink a cold beer together :-)
>
> Well, we are both in London ;-)
>
>
> > I would agree with Sebb that setting inceptionYear is not helpful. It
> > varies too much from commons project to project to be a useful default;
> > it's more likely to just cause projects to declare an incorrect
> > inceptionYear.
>
> +1
>
>
> > The compile.source and compile.target settings seem reasonable though.
> >
> > The "target" setting means that by default the bytecode is at least
> > loadable on a 1.3 JVM, which avoids projects accidentally generating
> > 1.5-only bytecode, while doing no great harm (a very minor performance
> > penalty for projects that forget to set it). That seems useful.
> >
> > The "source" setting means use of any jsf1.4 or jsf1.5 language features
> > will cause a compile error. This
> > seems a good idea, preventing projects that mean to be 1.3 or 1.4
> > compatible from accidentally introducing incompatible syntax. Projects
> > that want to be 1.5-compatible will pretty quickly override this setting!
> >
> > Of course nothing currently stops projects from invoking methods that
> > are not in the target runtime, but these settings seem to be at least a
> > good start.
>
> I agree with most of the above - the last para is where the problem lies.
>
> I think it's important that the Manifests contain the compiler version
> that the product is intended for.
>
> And hopefully the compiler versions will soon be used to provide JVM
> dependency information on the web-site.
>
> I think it's important that the information on the web-site and in the
> manifest is accurate.
>
> At present, it's very easy for a project to default to 1.3, and the
> build etc will work fine in Maven2 (which requires 1.4). But the
> resulting code may well fail on 1.3.
>
> If anything, the default for Maven2 builds should be 1.4, since M2 requires 1.4.
> That would at least allow the default to be built and tested properly with M2.
>
> As it stands, the default can produce code that will not run correctly
> on the specified version.
>
>
>
> > Cheers,
> >
> > Simon
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 27, 2008 at 4:15 PM, sebb <se...@gmail.com> wrote:
> On 27/02/2008, simon.kitching@chello.at <si...@chello.at> wrote:
> > Niall Pemberton schrieb:
> >
> > > On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
> > >
> > >> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > >> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> > >> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > >> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > >> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > >> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > > <inceptionYear>2001</inceptionYear>
> > >> > > > > > > <maven.compile.source>1.3</maven.compile.source>
> > >> > > > > > > <maven.compile.target>1.3</maven.compile.target>
> > >> > > > > >
> > >> > > > > >
> > >> >
> > >> >
> >
> > >> > The whole idea of commons-parent is that we don't have to explicitly
> > >> > configure everything in the component pom's - you set it in the parent
> > >> > and override only if necessary. So while it may only be three lines in
> > >> > EACH component pom - I'm against adopting what you say as a principle.
> > >> >
> > >>
> > >> I am not suggesting that all the defaults in the parent POM should be removed.
> > >>
> > >> What I am saying is that it *is necessary* for projects to override
> > >> *these items*.
> > >>
> > >
> > > Well I don't agree with you - its a bad principle to set requiring
> > > duplicatiion for any items and IMO *its not necessary* for *these
> > > items*
> >
> >
> > Guys, you need to drink a cold beer together :-)
>
> Well, we are both in London ;-)
Speaking of beer, London and Commons - Stephen Colebourne is giving a
talk on closures in java at the London JAVAWUG on monday:
http://www.jroller.com/javawug/entry/javawug_bof_35_closures_in
Its free but requires registration
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by sebb <se...@gmail.com>.
On 27/02/2008, simon.kitching@chello.at <si...@chello.at> wrote:
> Niall Pemberton schrieb:
>
> > On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> >> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> >> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> >> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> >> > > > > >
> >> > > > > > > <inceptionYear>2001</inceptionYear>
> >> > > > > > > <maven.compile.source>1.3</maven.compile.source>
> >> > > > > > > <maven.compile.target>1.3</maven.compile.target>
> >> > > > > >
> >> > > > > >
> >> >
> >> >
>
> >> > The whole idea of commons-parent is that we don't have to explicitly
> >> > configure everything in the component pom's - you set it in the parent
> >> > and override only if necessary. So while it may only be three lines in
> >> > EACH component pom - I'm against adopting what you say as a principle.
> >> >
> >>
> >> I am not suggesting that all the defaults in the parent POM should be removed.
> >>
> >> What I am saying is that it *is necessary* for projects to override
> >> *these items*.
> >>
> >
> > Well I don't agree with you - its a bad principle to set requiring
> > duplicatiion for any items and IMO *its not necessary* for *these
> > items*
>
>
> Guys, you need to drink a cold beer together :-)
Well, we are both in London ;-)
> I would agree with Sebb that setting inceptionYear is not helpful. It
> varies too much from commons project to project to be a useful default;
> it's more likely to just cause projects to declare an incorrect
> inceptionYear.
+1
> The compile.source and compile.target settings seem reasonable though.
>
> The "target" setting means that by default the bytecode is at least
> loadable on a 1.3 JVM, which avoids projects accidentally generating
> 1.5-only bytecode, while doing no great harm (a very minor performance
> penalty for projects that forget to set it). That seems useful.
>
> The "source" setting means use of any jsf1.4 or jsf1.5 language features
> will cause a compile error. This
> seems a good idea, preventing projects that mean to be 1.3 or 1.4
> compatible from accidentally introducing incompatible syntax. Projects
> that want to be 1.5-compatible will pretty quickly override this setting!
>
> Of course nothing currently stops projects from invoking methods that
> are not in the target runtime, but these settings seem to be at least a
> good start.
I agree with most of the above - the last para is where the problem lies.
I think it's important that the Manifests contain the compiler version
that the product is intended for.
And hopefully the compiler versions will soon be used to provide JVM
dependency information on the web-site.
I think it's important that the information on the web-site and in the
manifest is accurate.
At present, it's very easy for a project to default to 1.3, and the
build etc will work fine in Maven2 (which requires 1.4). But the
resulting code may well fail on 1.3.
If anything, the default for Maven2 builds should be 1.4, since M2 requires 1.4.
That would at least allow the default to be built and tested properly with M2.
As it stands, the default can produce code that will not run correctly
on the specified version.
> Cheers,
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 27, 2008 at 3:50 PM, simon.kitching@chello.at
<si...@chello.at> wrote:
> Niall Pemberton schrieb:
>
> > On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> >> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> >> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> >> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> >> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> >> > > > > >
> >> > > > > > > <inceptionYear>2001</inceptionYear>
> >> > > > > > > <maven.compile.source>1.3</maven.compile.source>
> >> > > > > > > <maven.compile.target>1.3</maven.compile.target>
> >> > > > > >
> >> > > > > >
> >> >
> >> >
>
> >> > The whole idea of commons-parent is that we don't have to explicitly
> >> > configure everything in the component pom's - you set it in the parent
> >> > and override only if necessary. So while it may only be three lines in
> >> > EACH component pom - I'm against adopting what you say as a principle.
> >> >
> >>
> >> I am not suggesting that all the defaults in the parent POM should be removed.
> >>
> >> What I am saying is that it *is necessary* for projects to override
> >> *these items*.
> >>
> >
> > Well I don't agree with you - its a bad principle to set requiring
> > duplicatiion for any items and IMO *its not necessary* for *these
> > items*
>
> Guys, you need to drink a cold beer together :-)
Always ready for a beer and happy to buy a round at ApacheCon :)
> I would agree with Sebb that setting inceptionYear is not helpful. It
> varies too much from commons project to project to be a useful default;
> it's more likely to just cause projects to declare an incorrect
> inceptionYear.
But it reflects the inception year of commons as a whole and taking it
out doesn't make it correct in components. If its that big a deal then
go through all the components poms and check that its present and
correct.
Niall
> The compile.source and compile.target settings seem reasonable though.
>
> The "target" setting means that by default the bytecode is at least
> loadable on a 1.3 JVM, which avoids projects accidentally generating
> 1.5-only bytecode, while doing no great harm (a very minor performance
> penalty for projects that forget to set it). That seems useful.
>
> The "source" setting means use of any jsf1.4 or jsf1.5 language features
> will cause a compile error. This
> seems a good idea, preventing projects that mean to be 1.3 or 1.4
> compatible from accidentally introducing incompatible syntax. Projects
> that want to be 1.5-compatible will pretty quickly override this setting!
>
> Of course nothing currently stops projects from invoking methods that
> are not in the target runtime, but these settings seem to be at least a
> good start.
>
> Cheers,
> Simon
>
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Niall Pemberton schrieb:
> On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
>
>> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
>> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
>> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
>> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
>> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
>> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
>> > > > > >
>> > > > > > > <inceptionYear>2001</inceptionYear>
>> > > > > > > <maven.compile.source>1.3</maven.compile.source>
>> > > > > > > <maven.compile.target>1.3</maven.compile.target>
>> > > > > >
>> > > > > >
>> >
>> >
>> > The whole idea of commons-parent is that we don't have to explicitly
>> > configure everything in the component pom's - you set it in the parent
>> > and override only if necessary. So while it may only be three lines in
>> > EACH component pom - I'm against adopting what you say as a principle.
>> >
>>
>> I am not suggesting that all the defaults in the parent POM should be removed.
>>
>> What I am saying is that it *is necessary* for projects to override
>> *these items*.
>>
>
> Well I don't agree with you - its a bad principle to set requiring
> duplicatiion for any items and IMO *its not necessary* for *these
> items*
Guys, you need to drink a cold beer together :-)
I would agree with Sebb that setting inceptionYear is not helpful. It
varies too much from commons project to project to be a useful default;
it's more likely to just cause projects to declare an incorrect
inceptionYear.
The compile.source and compile.target settings seem reasonable though.
The "target" setting means that by default the bytecode is at least
loadable on a 1.3 JVM, which avoids projects accidentally generating
1.5-only bytecode, while doing no great harm (a very minor performance
penalty for projects that forget to set it). That seems useful.
The "source" setting means use of any jsf1.4 or jsf1.5 language features
will cause a compile error. This
seems a good idea, preventing projects that mean to be 1.3 or 1.4
compatible from accidentally introducing incompatible syntax. Projects
that want to be 1.5-compatible will pretty quickly override this setting!
Of course nothing currently stops projects from invoking methods that
are not in the target runtime, but these settings seem to be at least a
good start.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 27, 2008 at 3:09 PM, sebb <se...@gmail.com> wrote:
>
> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> > > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > > <inceptionYear>2001</inceptionYear>
> > > > > > > <maven.compile.source>1.3</maven.compile.source>
> > > > > > > <maven.compile.target>1.3</maven.compile.target>
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yes. But what's the problem? For the inceptionYear, that has to be
> > > > > > specified whenever you use a parent POM. And for the compilation
> > > > > > source and target properties: That has been in the commons-parent POM
> > > > > > since quite some time (and been quite successful, IMO).
> > > > > >
> > > > >
> > > > > The problem is that the default generally works, even if it is not
> > > > > correct for the project.
> > > > > So allowing projects to default these values is wrong - each project
> > > > > needs to make a conscious choice.
> > > >
> > > >
> > > > Defaults are good
> > > >
> > >
> > > Categorical statements are bad ;-)
> > >
> > > I agree that avoiding unnecessary extra work is good - however in this
> > > case, I believe that the extra work needs to be done.
> > >
> > > We're not talking about major rework here - at most 3 lines need to be
> > > added to the child POM. This only has to be done once, and only when
> > > updating the parent POM (which is another edit in the same file).
> > >
> > > Yes, the compiler versions may need to be updated later, but that was
> > > always true.
> >
> >
> > The whole idea of commons-parent is that we don't have to explicitly
> > configure everything in the component pom's - you set it in the parent
> > and override only if necessary. So while it may only be three lines in
> > EACH component pom - I'm against adopting what you say as a principle.
> >
>
> I am not suggesting that all the defaults in the parent POM should be removed.
>
> What I am saying is that it *is necessary* for projects to override
> *these items*.
Well I don't agree with you - its a bad principle to set requiring
duplicatiion for any items and IMO *its not necessary* for *these
items*.
Niall
> > Niall
> >
> >
> > > > > If the parent POM has to have an inceptionYear, then I suggest it is
> > > > > set to something like TBD (or 1900 if it has to be numeric) so that it
> > > > > is obvious when it has not been set by the project.
> > > > >
> > > > > [Likewise, if the versions have to be specified, then set them to
> > > > > 99.99 or somesuch]
> > > >
> > > >
> > > > I believe 2001 was the inception of commons:
> > > > http://commons.markmail.org/search/?q=
> > >
> > > But not of all Commons components, and the NOTICE file is supposed to
> > > reflect the particular artifacts that are being distributed.
> > >
> > > > Niall
> > > >
> > > > >
> > > > > >
> > > > > > Jochen
> > >
> > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by sebb <se...@gmail.com>.
On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> > On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > > > >
> > > > > > <inceptionYear>2001</inceptionYear>
> > > > > > <maven.compile.source>1.3</maven.compile.source>
> > > > > > <maven.compile.target>1.3</maven.compile.target>
> > > > >
> > > > >
> > > > >
> > > > > Yes. But what's the problem? For the inceptionYear, that has to be
> > > > > specified whenever you use a parent POM. And for the compilation
> > > > > source and target properties: That has been in the commons-parent POM
> > > > > since quite some time (and been quite successful, IMO).
> > > > >
> > > >
> > > > The problem is that the default generally works, even if it is not
> > > > correct for the project.
> > > > So allowing projects to default these values is wrong - each project
> > > > needs to make a conscious choice.
> > >
> > >
> > > Defaults are good
> > >
> >
> > Categorical statements are bad ;-)
> >
> > I agree that avoiding unnecessary extra work is good - however in this
> > case, I believe that the extra work needs to be done.
> >
> > We're not talking about major rework here - at most 3 lines need to be
> > added to the child POM. This only has to be done once, and only when
> > updating the parent POM (which is another edit in the same file).
> >
> > Yes, the compiler versions may need to be updated later, but that was
> > always true.
>
>
> The whole idea of commons-parent is that we don't have to explicitly
> configure everything in the component pom's - you set it in the parent
> and override only if necessary. So while it may only be three lines in
> EACH component pom - I'm against adopting what you say as a principle.
>
I am not suggesting that all the defaults in the parent POM should be removed.
What I am saying is that it *is necessary* for projects to override
*these items*.
> Niall
>
>
> > > > If the parent POM has to have an inceptionYear, then I suggest it is
> > > > set to something like TBD (or 1900 if it has to be numeric) so that it
> > > > is obvious when it has not been set by the project.
> > > >
> > > > [Likewise, if the versions have to be specified, then set them to
> > > > 99.99 or somesuch]
> > >
> > >
> > > I believe 2001 was the inception of commons:
> > > http://commons.markmail.org/search/?q=
> >
> > But not of all Commons components, and the NOTICE file is supposed to
> > reflect the particular artifacts that are being distributed.
> >
> > > Niall
> > >
> > > >
> > > > >
> > > > > Jochen
> >
> >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 27, 2008 at 2:27 PM, sebb <se...@gmail.com> wrote:
> On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > > >
> > > > > <inceptionYear>2001</inceptionYear>
> > > > > <maven.compile.source>1.3</maven.compile.source>
> > > > > <maven.compile.target>1.3</maven.compile.target>
> > > >
> > > >
> > > >
> > > > Yes. But what's the problem? For the inceptionYear, that has to be
> > > > specified whenever you use a parent POM. And for the compilation
> > > > source and target properties: That has been in the commons-parent POM
> > > > since quite some time (and been quite successful, IMO).
> > > >
> > >
> > > The problem is that the default generally works, even if it is not
> > > correct for the project.
> > > So allowing projects to default these values is wrong - each project
> > > needs to make a conscious choice.
> >
> >
> > Defaults are good
> >
>
> Categorical statements are bad ;-)
>
> I agree that avoiding unnecessary extra work is good - however in this
> case, I believe that the extra work needs to be done.
>
> We're not talking about major rework here - at most 3 lines need to be
> added to the child POM. This only has to be done once, and only when
> updating the parent POM (which is another edit in the same file).
>
> Yes, the compiler versions may need to be updated later, but that was
> always true.
The whole idea of commons-parent is that we don't have to explicitly
configure everything in the component pom's - you set it in the parent
and override only if necessary. So while it may only be three lines in
EACH component pom - I'm against adopting what you say as a principle.
Niall
> > > If the parent POM has to have an inceptionYear, then I suggest it is
> > > set to something like TBD (or 1900 if it has to be numeric) so that it
> > > is obvious when it has not been set by the project.
> > >
> > > [Likewise, if the versions have to be specified, then set them to
> > > 99.99 or somesuch]
> >
> >
> > I believe 2001 was the inception of commons:
> > http://commons.markmail.org/search/?q=
>
> But not of all Commons components, and the NOTICE file is supposed to
> reflect the particular artifacts that are being distributed.
>
> > Niall
> >
> > >
> > > >
> > > > Jochen
>
>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by sebb <se...@gmail.com>.
On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> > On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> > >
> > > > <inceptionYear>2001</inceptionYear>
> > > > <maven.compile.source>1.3</maven.compile.source>
> > > > <maven.compile.target>1.3</maven.compile.target>
> > >
> > >
> > >
> > > Yes. But what's the problem? For the inceptionYear, that has to be
> > > specified whenever you use a parent POM. And for the compilation
> > > source and target properties: That has been in the commons-parent POM
> > > since quite some time (and been quite successful, IMO).
> > >
> >
> > The problem is that the default generally works, even if it is not
> > correct for the project.
> > So allowing projects to default these values is wrong - each project
> > needs to make a conscious choice.
>
>
> Defaults are good
>
Categorical statements are bad ;-)
I agree that avoiding unnecessary extra work is good - however in this
case, I believe that the extra work needs to be done.
We're not talking about major rework here - at most 3 lines need to be
added to the child POM. This only has to be done once, and only when
updating the parent POM (which is another edit in the same file).
Yes, the compiler versions may need to be updated later, but that was
always true.
>
> > If the parent POM has to have an inceptionYear, then I suggest it is
> > set to something like TBD (or 1900 if it has to be numeric) so that it
> > is obvious when it has not been set by the project.
> >
> > [Likewise, if the versions have to be specified, then set them to
> > 99.99 or somesuch]
>
>
> I believe 2001 was the inception of commons:
> http://commons.markmail.org/search/?q=
But not of all Commons components, and the NOTICE file is supposed to
reflect the particular artifacts that are being distributed.
> Niall
>
> >
> > >
> > > Jochen
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Feb 27, 2008 at 2:07 PM, sebb <se...@gmail.com> wrote:
> On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> > On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> >
> > > <inceptionYear>2001</inceptionYear>
> > > <maven.compile.source>1.3</maven.compile.source>
> > > <maven.compile.target>1.3</maven.compile.target>
> >
> >
> >
> > Yes. But what's the problem? For the inceptionYear, that has to be
> > specified whenever you use a parent POM. And for the compilation
> > source and target properties: That has been in the commons-parent POM
> > since quite some time (and been quite successful, IMO).
> >
>
> The problem is that the default generally works, even if it is not
> correct for the project.
> So allowing projects to default these values is wrong - each project
> needs to make a conscious choice.
Defaults are good
> If the parent POM has to have an inceptionYear, then I suggest it is
> set to something like TBD (or 1900 if it has to be numeric) so that it
> is obvious when it has not been set by the project.
>
> [Likewise, if the versions have to be specified, then set them to
> 99.99 or somesuch]
I believe 2001 was the inception of commons:
http://commons.markmail.org/search/?q=
Niall
>
> >
> > Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by sebb <se...@gmail.com>.
On 27/02/2008, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
>
> > <inceptionYear>2001</inceptionYear>
> > <maven.compile.source>1.3</maven.compile.source>
> > <maven.compile.target>1.3</maven.compile.target>
>
>
>
> Yes. But what's the problem? For the inceptionYear, that has to be
> specified whenever you use a parent POM. And for the compilation
> source and target properties: That has been in the commons-parent POM
> since quite some time (and been quite successful, IMO).
>
The problem is that the default generally works, even if it is not
correct for the project.
So allowing projects to default these values is wrong - each project
needs to make a conscious choice.
==
If the parent POM has to have an inceptionYear, then I suggest it is
set to something like TBD (or 1900 if it has to be numeric) so that it
is obvious when it has not been set by the project.
[Likewise, if the versions have to be specified, then set them to
99.99 or somesuch]
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Feb 27, 2008 at 2:42 PM, sebb <se...@gmail.com> wrote:
> <inceptionYear>2001</inceptionYear>
> <maven.compile.source>1.3</maven.compile.source>
> <maven.compile.target>1.3</maven.compile.target>
Yes. But what's the problem? For the inceptionYear, that has to be
specified whenever you use a parent POM. And for the compilation
source and target properties: That has been in the commons-parent POM
since quite some time (and been quite successful, IMO).
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: [VOTE] Release commons-parent 8
Posted by sebb <se...@gmail.com>.
The parent POM defines these items:
<inceptionYear>2001</inceptionYear>
<maven.compile.source>1.3</maven.compile.source>
<maven.compile.target>1.3</maven.compile.target>
Surely these should (MUST) be defined by the specific child POMs?
On 27/02/2008, Niall Pemberton <ni...@gmail.com> wrote:
> +1 from me.
>
>
> Niall
>
>
> On Wed, Feb 27, 2008 at 1:05 PM, Niall Pemberton
> <ni...@gmail.com> wrote:
> > Hi,
> >
> > I'd like to release version 8 of the commons-parent pom - the changes
> > since the last release are:
> > - re-order mailing archives
> > - configure the maven-bundle-plugin (for OSGi)
> > - configure the commons-build-plugin (for OSGi)
> > - maven-install-plugin 2.1 --> 2.2
> > - maven-surefire-plugin 2.3 --> 2.4.2
> > - specify encoding for the javadoc and compiler plugins
> > - specify a "phase" for the javadoc and sources plugins in the
> > rc/release profiles
> > - configure the install plugin to create checksums in the rc/release profiles
> >
> > A full diff of the pom.xml can be found at this address:
> > http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=631209&r2=611431&diff_format=h
> >
> > The version number in the pom will be updated automatically during the
> > release process.
> >
> > [ ] +1
> > [ ] =0
> > [ ] -1
> >
> > Vote is open for 72 hours
> >
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
+1 from me.
Niall
On Wed, Feb 27, 2008 at 1:05 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> Hi,
>
> I'd like to release version 8 of the commons-parent pom - the changes
> since the last release are:
> - re-order mailing archives
> - configure the maven-bundle-plugin (for OSGi)
> - configure the commons-build-plugin (for OSGi)
> - maven-install-plugin 2.1 --> 2.2
> - maven-surefire-plugin 2.3 --> 2.4.2
> - specify encoding for the javadoc and compiler plugins
> - specify a "phase" for the javadoc and sources plugins in the
> rc/release profiles
> - configure the install plugin to create checksums in the rc/release profiles
>
> A full diff of the pom.xml can be found at this address:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=631209&r2=611431&diff_format=h
>
> The version number in the pom will be updated automatically during the
> release process.
>
> [ ] +1
> [ ] =0
> [ ] -1
>
> Vote is open for 72 hours
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release commons-parent 8
Posted by Jochen Wiedmann <jo...@gmail.com>.
+1
--
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
[RESULT][VOTE] Release commons-parent 8
Posted by Niall Pemberton <ni...@gmail.com>.
This vote has passed with four +1 votes from the following people:
Jochen Wiedmann
Niall Pemberton
James Carman
Jörg Schaible
Thanks, I'll cut the release shortly.
Niall
On Wed, Feb 27, 2008 at 1:05 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> Hi,
>
> I'd like to release version 8 of the commons-parent pom - the changes
> since the last release are:
> - re-order mailing archives
> - configure the maven-bundle-plugin (for OSGi)
> - configure the commons-build-plugin (for OSGi)
> - maven-install-plugin 2.1 --> 2.2
> - maven-surefire-plugin 2.3 --> 2.4.2
> - specify encoding for the javadoc and compiler plugins
> - specify a "phase" for the javadoc and sources plugins in the
> rc/release profiles
> - configure the install plugin to create checksums in the rc/release profiles
>
> A full diff of the pom.xml can be found at this address:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=631209&r2=611431&diff_format=h
>
> The version number in the pom will be updated automatically during the
> release process.
>
> [ ] +1
> [ ] =0
> [ ] -1
>
> Vote is open for 72 hours
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org