aspose file tools*
The moose likes Ant, Maven and Other Build Tools and the fly likes Building different branches with different JDK on same box? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Building different branches with different JDK on same box?" Watch "Building different branches with different JDK on same box?" New topic
Author

Building different branches with different JDK on same box?

Tom Cunningham
Greenhorn

Joined: Dec 09, 2004
Posts: 5
Our build process so far has been relatively simple - we build each branch every night using the 1.4.2 JDK. Our servlets and JSP's are hosted using the same JVM.

However, we are moving to 1.5, but only one of the branches right now is going to be using the 1.5 JDK, and the other branches will still be deployed using the 1.4.2 JDK. How do other people handle this? Is it okay to build using "-source 1.4" on the 1.5 JDK, and then ship using the 1.4 JDK? Is there a better way of specifying in ant which JDK should be used?

My two biggest problems are that I don't want to make changes to the way that the other branches build because I'm afraid it will turn into a QA nightmare. I'd love it if they could continue to build using the 1.4.2 JDK rather than build with the 1.5.0 JDK in 1.4 mode. However, we build all of the branches on the same box, and developers are going to need to make changes on multiple branches on their own machines - meaning that they will have to build using both 1.4.2 and 1.5.0 locally.

If I was doing this all on Linux, it would be easy - symlinks would fix this up for me quickly. However, I'm stuck on Windows. How have other people dealt with this problem?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

First off, read http://ant.apache.org/manual/CoreTasks/javac.html for information on how java compilers are selected and invoked by Ant.

Be sure to note that the "source" option on javac and other tools such as javadoc indicate the source code compliance level, and NOT the compiler version to select. Source code compliance is used to flag things like the use of the 1.4 "assert" mechanism when you're targeting a 1.3 or earlier runtime and to avoid use of bytecodes incompatible with that runtime version. [Which is the #1 difference between Java and Microsoft-based development where backwards compatability is a poor joke, not an enforced standard.]

I really recommend that if your're expecting to compile for different target VM levels on different project subsystems, you split out the modules into subprojects just to keep the lines from blurring.

Beyond that, suffice it to asy that you can do all sorts of wonderful things using Ant property definitions.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Building different branches with different JDK on same box?