Bug 44849 - ant does not load libraries from ~/.ant/lib when ant.jar is on the classpath
Summary: ant does not load libraries from ~/.ant/lib when ant.jar is on the classpath
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2008-04-21 13:25 UTC by Trevin Beattie
Modified: 2008-04-21 15:47 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Trevin Beattie 2008-04-21 13:25:26 UTC
I've been investigating a problem with loading 3rd-party tasks like ivy, obfuscate, and jalopy from the ~/.ant/lib directory on a Fedora Core 6 system with the vendor-provided ant-1.6.5 package.  When I upgraded to ant-1.7.0 from FC8 it had the same problem, but the problem does not exist with ant-1.6.2 from FC4.  When I build and install ant-1.7.0 in my home directory, it will work only if the vendor ant package is not installed or I run ant with the --noconfig option.

After trying to start the launcher directly with various configurations, I discovered that while the following command works:

java -classpath /home/tbeattie/src/ant-1.7.0/lib/ant-launcher.jar -Dant.home=/home/tbeattie/src/ant-1.7.0 -Dant.library.dir=/home/tbeattie/src/ant-1.7.0/lib org.apache.tools.ant.launch.Launcher -cp ''

this command fails:

java -classpath /home/tbeattie/src/ant-1.7.0/lib/ant-launcher.jar:/home/tbeattie/src/ant-1.7.0/lib/ant.jar -Dant.home=/home/tbeattie/src/ant-1.7.0 -Dant.library.dir=/home/tbeattie/src/ant-1.7.0/lib org.apache.tools.ant.launch.Launcher -cp ''

The only difference is adding ant.jar to the -classpath (and this is the locally installed ant.jar, not the vendor ant.jar).  The error is:

Buildfile: build.xml


/home/tbeattie/src/apache-ivy-2.0.0-beta2/src/example/hello-ivy/build.xml:38: Problem: failed to create task or type antlib:org.apache.ivy.ant:retrieve
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.

This appears to be an antlib declaration. 
Action: Check that the implementing library exists in one of:
        -a directory added on the command line with the -lib argument

Total time: 0 seconds

Note that the system-wide ant configuration file /etc/ant.conf installed by Fedora sets rpm_mode=true by default, which causes the ant startup script to set LOCALCLASSPATH to include ant.jar.  Since build-classpath only searches system java directories, I don't think it's possible to test a local install of the ant startup script with "rpm_mode=true" (it can't find ant-launcher).  You can only test with a system install.

The converse cannot be directly tested on a vendor ant install because it cannot find org.apache.tools.ant.Main if ant.jar is not on the classpath.

I believe this is the same bug that was reported in 35060.  I am not certain whether it is related to bug 41587.
Comment 1 Peter Reilly 2008-04-21 15:30:31 UTC
?why is this a bug?

ant.jar is *not* meant to be on the classpath,
I have *no* idea why it would work with ant 1.6.2
as the way that ~/.ant/lib and $ANT_HOME/lib work
is that ant_launcher.jar creates a classloader
that contains ant.jar + all the jars in $ANT_HOME/lib
+ all the jars in ~/.ant/lib and any jars in directories
specified on the the command line specified by -lib.

This means that ant.jar classes have (import) access to jars in ~/.ant/lib
and $ANT_HOME/lib - which is the way that optional tasks work.

If ant.jar is on the classpath, this mechanism does not work.

(I.e the jpackage version of ant does not support ~/.ant/lib).

Comment 2 Trevin Beattie 2008-04-21 15:47:26 UTC
I did not know that.  Apparently, neither does the JPackage Project, which is the basis for the Red Hat / Fedora packages.  I'll open a bug report with Red Hat.