I have been happily developing and testing a Grails application, which includes Java source, using JDK 1.6. The development and testing went fine. I experimented with deploying the application to Tomcat on my local system, which went without a hitch. Unfortunately, when I deployed it to a different system, I got an UnsupportedClassVersionError thrown when starting Tomcat. The deployment environment uses Java 1.5.
I read through the Groovy scripts (notably Init and Compile) that come with Grails. I found that I could work around the issue by changing the Compile.groovy script to specify the target in Ant’s javac task. However, I didn’t care for this solution as my changes would get lost when I upgrade to the next version of Grails. I kept looking for a better solution and found one, based on the Ant 1.7.0, which is included in Grails 1.0.1.
It seems that the Apache folks have introduced two new properties in Ant 1.7.0 which override the default source and target of the javac task. These are: ant.build.javac.source and ant.build.javac.target. Now that we know we can override the source and target of Ant’s javac task, where do we put it?
One solution was discovered in reading the Init.groovy script. It loads build.properties from the GRAILS_HOME location (specified by the environment variable with the same name). So appending the following lines to that file resolved my problem.
ant.build.javac.target=1.5
ant.build.javac.source=1.5
This is no better as a new installation of Grails will provide a new build.properties that you will have to remember to edit. A better solution would be for the Init.groovy script to process a build.properties file in the grails application directory, if one exists.
Another possible solution is to create a small Ant build.xml file that you use instead of the grails.bat/grails.sh script directly. This build.xml file could define the above properties (or load them from a local build.properties file) and invoke the grails.bat/grails.sh script (using Ant’s exec task) with the appropriate arguments. This option feels best to me at the moment.
Perhaps someone on the Grails team will also like my recommendation for an application build.properties file and implement that in an upcoming release.