On Fri, Jun 10, 2011 at 8:45 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : We could compile under 1.6 and have a jenkins (ant) target to check > : binary 1.5 compatibility -- bytecode versions and std. API calls. This > : way we could use 1.6, @Override annotations, etc. and still ensure 1.5 > : support for folks that need it. > > -0 ... wouldn't that mean that users running *actual* 1.5 JVM installs > couldn't compile from source? I think it would be a bad idea to say that > our "compile" JVM requirements are differnet then our "run" JVM > requirements. I'd be more in favor of requireing 1.6 then having a weird > build where 1.5 folks could use our binary releases but not compile > themselves.
I agree with you completely (a rare occasion, i know!). I think it would be better to just require 1.6 if we want to go that route. Personally I find myself often breaking the build because the solr bits require 1.6 but the lucene bits require 1.5 (and see below) > lucene/build.xml has a target called "nightly" but it's not actually used > directly. The number of things hudson does has gotten kind of complicated... > Just for reference, there are two reasons for this: 1. lack of a java 5 JRE on freebsd that is capable of actually compiling+running all of our tests. I've tried every option here, including the linux one under emulation, but its fair to say without bragging that our tests do actually stress a JRE a little bit, so its really gotta be solid. 2. using java 6 with -source/-target for java 5 doesn't actually catch invalid java 5, especially @Override on interface methods. However, the native java 6 port to freebsd is quite solid (passes all of our tests), and is actually being maintained and improved. Java 5 is dead technology and I don't think anyone is working on solving #1. Because of this, we must compile the lucene/modules bits with the java 5 COMPILER, but the solr bits with java 6 COMPILER to catch all compile errors, then run all tests with java 6... currently the java5 compiler we have on hudson is only useful really for its "javac". This is why hudson is complicated. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
