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 <[EMAIL PROTECTED]> wrote: > On 27/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Niall Pemberton schrieb: > > > > > On Wed, Feb 27, 2008 at 3:09 PM, sebb <[EMAIL PROTECTED]> wrote: > > > > > >> On 27/02/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > >> > On Wed, Feb 27, 2008 at 2:27 PM, sebb <[EMAIL PROTECTED]> wrote: > > >> > > On 27/02/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > >> > > > On Wed, Feb 27, 2008 at 2:07 PM, sebb <[EMAIL PROTECTED]> > wrote: > > >> > > > > On 27/02/2008, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > > >> > > > > > On Wed, Feb 27, 2008 at 2:42 PM, sebb <[EMAIL > PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
