commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [VOTE] Release commons-parent 8
Date Wed, 27 Feb 2008 16:14:32 GMT
On Wed, Feb 27, 2008 at 3:50 PM, simon.kitching@chello.at
<simon.kitching@chello.at> wrote:
> Niall Pemberton schrieb:
>
> > On Wed, Feb 27, 2008 at 3:09 PM, sebb <sebbaz@gmail.com> wrote:
>  >
>  >> On 27/02/2008, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  >>  > On Wed, Feb 27, 2008 at 2:27 PM, sebb <sebbaz@gmail.com> wrote:
>  >>  >  > On 27/02/2008, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>  >>  >  >  > On Wed, Feb 27, 2008 at 2:07 PM, sebb <sebbaz@gmail.com>
wrote:
>  >>  >  >  >  > On 27/02/2008, Jochen Wiedmann <jochen.wiedmann@gmail.com>
wrote:
>  >>  >  >  >  >  > On Wed, Feb 27, 2008 at 2:42 PM, sebb <sebbaz@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


Mime
View raw message