Bug 141058 - ant.home not set by ant binary (but is set by classic-ant script)
ant.home not set by ant binary (but is set by classic-ant script)
Product: Fedora
Classification: Fedora
Component: ant (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Vadim Nasardinov
Depends On:
  Show dependency treegraph
Reported: 2004-11-28 18:59 EST by Daniel L. Rall
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-10 15:58:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
bz141058.sh (242 bytes, text/plain)
2005-11-10 15:56 EST, Vadim Nasardinov
no flags Details

  None (edit)
Description Daniel L. Rall 2004-11-28 18:59:02 EST
Description of problem:

The ant.home system property (e.g. System.getProperty()) is not set as
for the gcj-compiled binary.  This problem is not present for the
classic-ant shell script.

This is especially important when writing Ant extensions while compile
against Ant itself (or its existing set of optional extension Tasks).

See revision 106859 of Velocity DVSL
<http://svn.apache.org/viewcvs.cgi/jakarta/velocity-dvsl/trunk/> for
an example of a work-around I had to write for this problem (build.xml
and default.properties were affected by the change).

Version-Release number of selected component (if applicable):

$ rpm -q ant

How reproducible:

Try using the ant.home property.  For instance, try setting ant.jar to

Actual results:

ant.home is not set, meaning that any JAR file path set relative to to
ant.home is unusable.

Expected results:

ant.home should always be set per ant script.

Additional info:

You can sometimes use the ANT_HOME environment variable as a
work-around, but this is not always set (its what ant.home is derived
from in classic-ant).
Comment 1 Daniel L. Rall 2004-11-29 16:46:24 EST
Incidently, here's how ant.home gets set from the ANT_HOME environment
variable in the classic-ant shell script:

$ grep 'ant\.home' `which classic-ant`
-Dant.home="${ANT_HOME}" -Djikes.class.path="$JIKESPATH"
-Dcygwin.user.home="$CYGHOME" org.apache.tools.ant.Main $ANT_ARGS "$@"
-Dant.home="${ANT_HOME}" -Dcygwin.user.home="$CYGHOME"
org.apache.tools.ant.Main $ANT_ARGS "$@"
-Dant.home="${ANT_HOME}" -Djikes.class.path="$JIKESPATH"
org.apache.tools.ant.Main $ANT_ARGS "$@"
-Dant.home="${ANT_HOME}" org.apache.tools.ant.Main $ANT_ARGS "$@"
Comment 3 Matthew Miller 2005-04-26 11:25:20 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 4 Daniel L. Rall 2005-04-26 15:16:51 EDT
Due to the native-compiled version of the ant executable, this is still a
problem in FC3, and will be a problem in FC4 as well.  Please let me know what
additional information I can provide.
Comment 5 Matthew Miller 2005-04-26 15:24:02 EDT
Thanks. I'm going to set this to version "devel" for FC4.
Comment 6 Gary Benson 2005-04-27 04:21:33 EDT
This won't be an issue for FC4.  Current rawhide has bytecode ant, and the new
BC ABI in libgcj means that stuff shouldn't break when we roll out the native
stuff (Real Soon Now™).
Comment 7 Daniel L. Rall 2005-04-27 18:51:16 EDT
Gary, thanks for the feedback!  This bytecode API sounds like a major
improvement which will likely fix a ton of the classloading issues I've seen
with the native-compiled ant binary.  However, I'm unsure how it alone could fix
the setting of ant.home, a java.lang.System property which is set for the JVM by
all the traditional Ant invocation wrapper scripts, and assumed by many Ant
tasks and build.xml files to be available.

To fix this issue, it seems to me that some additional code would need to be
executed by the gcj-compiled binary on startup which performs the additional
operations handled by the traditional wrapper scripts (operations which occur
before any Java bytecode is ever executed).  Missing the ant.home system
property is only once instance of this class of problem; note other system
properties like jikes.class.path and cygwin.user.home which are set by the
snippet of the traditional shell wrapper script which I pasted into comment #1.

For most developer/end users of Ant, Ant is more than the its Java bytecodes. 
It's also that set of wrapper scripts which insulate the user from environment
specific issues which they'd prefer not to have to know about.  :-)
Comment 8 Gary Benson 2005-04-28 04:57:09 EDT
In FC4 we're using the standard ant wrapper scripts -- the gcj-compiled binary
is history.
Comment 9 Vadim Nasardinov 2005-11-10 15:56:02 EST
Created attachment 120903 [details]

simple test case
Comment 10 Vadim Nasardinov 2005-11-10 15:58:18 EST
Seems to work in FC4:

|$ curl -o bz141058.sh \
|  'https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120903'
|  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
|                                 Dload  Upload   Total   Spent    Left  Speed
|100   242  100   242    0     0    290      0 --:--:-- --:--:-- --:--:--  236k
|$ bash bz141058.sh
|Buildfile: /dev/fd/63
|     [echo] ant.home=/usr/share/ant
|Total time: 1 second

Comment 11 Daniel L. Rall 2005-11-10 19:13:01 EST
Nice work guys.  Verified on FC4.

Note You need to log in before you can comment on or make changes to this bug.