Greg Wilkins wrote:
So hopefully the tools.jar dependancy will soon be history. Thus anything done to support it in the short term should clearly be of a temporary nature.
well, if it's only temporary and we know it won't re-surface, there's no need to add it to policy.
I think Andrew Pimlott's point is good - I guess the problem has just moved to ant. But they appear to have done a better job of finding tools.jar themselves (Mmmm maybe that is only in their start script?)
From the ant.sh script:
if [ -n "$JAVA_HOME" ] ; then if [ -f "$JAVA_HOME/lib/tools.jar" ] ; then LOCALCLASSPATH="$LOCALCLASSPATH:$JAVA_HOME/lib/tools.jar" fi
[snip]
else echo "Warning: JAVA_HOME environment variable is not set." echo " If build fails because sun.* classes could not be found" echo " you will need to set the JAVA_HOME environment variable" echo " to the installation directory of java." fi
which makes things a bit difficult to deal with...
I personally use sun's tools.jar, 'cause it's easier to deal with. I wonder if making an installer script (in non-free, of course) which goes out and gets the j2ee implementation (a la the way the qmail installer is built), rolls a deb, etc. would be in order.
Which does nothing to address the tools.jar dependency, but at least gives a workaround...
glen
