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]
