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 resolve: BUILD FAILED /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: -/home/tbeattie/src/ant-1.7.0/lib -/home/tbeattie/.ant/lib -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.
?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). Peter
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.