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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
