Thanks, Simon! On 6/25/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Sat, 2005-06-25 at 21:34 -0700, Phil Steitz wrote: > > Before I roll an RC, I need consensus on how we should be doing this. > > I see three alternatives, with the PITA level increasing in order: > > > > 1. Don't worry, be happy - just set maven.compile.target=1.3 and use > > maven dist under 1.4 (or 1.5) to generate the jars and roll the > > distros. > > > > 2. Add the following to project.properties > > # Fill in path to build JDK or specify this in local build.properties > > # When building distribution jars, should use JDK 1.3 > > # maven.compile.executable= > > maven.compile.fork=true > > maven.compile.target=1.3 > > maven.jar.manifest=MANIFEST.MF > > then specify maven.compile.executable in build.properties and add a > > MANIFEST.MF file containing one line: > > Build-Jdk: 1.3 > > (maven will merge that one line into the manifest that it generates, > > making it correct). > > Option 2 looks good to me. (I presume you mean setting > maven.compile.executable in project.properties).
No, I meant build.properties, since that is where at least I put local stuff (things like maven.username and other local stuff) and maven will pick this up. I think commons-build has a build.properties.sample with this kind of thing. > > > I am by no means a jdk expert, but from what has been said above, it > > looks to me like 1 and 2 both carry some risk (the risk in 2 being due > > to lack of classpath control). It would seem, though, that if the > > tests all pass when compiled and run under 1.3 against the 1.4 jar, > > the risk in even 1. is small (assuming path coverage is good). > > I don't understand what you mean by "lack of classpath control". I think someone mentioned that maven.compile.executable just sets the path to the javac executable. The java classpath used could still include, e.g. rt.jar from the "parent" jdk. I don't think maven exposes properties like ant.bootclasspath and ant.classpath that allow you to control the classpath used when compiling the jar. It is quite possible that I have this wrong, but it makes sense to me (since maven builds the classpath from the POM). > > I would agree that compiling the core code under 1.4 or 1.5 then > compiling and running the tests under 1.3 is sufficient to assure 1.3 > compatibility. However I'm not sure that a simple and reliable way of > doing that can be found. Well, I have done it manually for math 1.1. It would have to be sort of a release validation step. I just hack the maven-generated build.xml to add the release jar to the classpath, omit compiling the code, compile the tests and run the test goal, executing ant with .antrc specifying the different jdks. I suppose I could commit the test-jar.xml and we could just always do this as part of validation. Actually, I have often thought that running the tests against the release jars (not the compiled classes) would be a good general release validation practice. I remember runniing into a funny velocity problem last year that did not show up in the tests because the there were some classes ommitted from the release jars. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
