Painful Ant Bite: A generous CLASSPATH and ant.bat out of hell
By kto on May 07, 2009
Painful ant bytes... ;\^) Starting to number them...
When ant runs, it sometimes uses temporary files using the java property java.io.tmpdir as the root of the temporary file area for the system. Unfortunately, the temp file used by ant isn't unique enough to prevent two processes running ant from bumping into each other. We had problems using the same machine to build both Solaris 32bit and Solaris 64bit at the same time. OUCH!
Jonathan came up with a good solution specific to the JDK in the langtools Makefile that runs ant. He defines the java.io.tmpdir property on the ant command line to be unique to this build area and platform:
ant -Djava.io.tmpdir='$(ABS_OUTPUTDIR)/build/ant-tmp' ...
The basic idea is to redefine the java.io.tmpdir (the root of the temporary file area) to something more unique to the circumstances, and ideally in a location that will get cleaned up at the right time.
Had a lovely time (<- sarcasm) tracking down a problem on Windows with JDK ant builds. Apparently on Windows, if you manage to get the ant.bat startup instead of the shell script version of the startup, commas are not allowed on the command line. So you cannot do this:
ant -Djavac.debuglevel=source,lines,vars OUCH!
This problem was reported here but nothing was done. Seems like a simple note in the User Manual was a minimum here.
So I downloaded the cpptasks for ant from the ant-contrib site. And it builds from the command line just fine with the latest ant, but it won't build using the ant that comes with NetBeans, and it won't build when loaded into NetBeans. So why is that? The build requires xercesImpl.jar, but the cpptasks build.xml file doesn't explicitly say that, so how did it find it in one case and not in another?
Turns out that the default behavior for the ant <javac> task is to include all the ant runtime classpath in your java compilation. Yipes! That seems like a horrible default if you ask me, depending on what ant decides to use in its runtime classpath, you get it all? :\^( OUCH!
Seems like every ant installation could potentially behave differently, depending on how ant is configured.
So I'm thinking I want to change all <javac> uses to <javac includeAntRuntime="false">
This was also talked about on a JavaLobby forum, with some helpful comments.