Frequently Asked Questions

Anteater comes with an unmodified, out-the-box version of Ant 1.5.1, and a custom 'anteater' script for running Anteater scripts. We include this with Anteater for three reasons:

As a convenience to users

Ant's main use is as a project build tool. Consequently many Anteater users won't have it installed. Bundling Ant with Anteater minimizes the hassle of getting started with Anteater.

To avoid Ant classloader problems

Due to Ant's (rather primitive) classloading system, it is easiest for Anteater jars to be loaded from the base classloader. We do this by modifying the 'ant' script to add Anteater jars to the CLASSPATH, the modified script being renamed to 'anteater'.

To set Anteater-specific properties

The 'anteater' script also provides an opportunity to set the ${anteater.home} and ${anteater.report} properties, used when generating HTML reports.

Due to the classloader problems mentioned in the previous FAQ, Anteater tasks cannot be run from a standard Ant install. See the section Invoking from Ant in the user manual for how to invoke Anteater scripts from an Ant script.

Invoke Anteater with anteater -Ddefault.debug=10. Debug levels vary from 0 (normal) to 10 (lots of debugging). See the Configuration section for more info (hint: you can configure lots of other properties like this).

By passing the JVM the http.proxyHost and http.proxyPort system properties, as described in the Action tasks section of the user manual.

We hope this bug is fixed in 0.9.11 and above. If you experience this, please send an email to aft-devel@lists.sourceforge.net"

Also, a handful of people have experienced this problem using vanilla Ant 1.5.1 on Compaq's Tru64 and DEC Alpha with OSF1 V4.0. This is a bug in the ant.sh script. The following ant-user post seems relevant:

From: "N. J. O'Neill" <njoneill@llnl.gov>
Subject: Re: Odd failure for 1.5Beta3 on Compaq Tru64 Unix (solution)
To: "Ant Users List" <ant-user@jakarta.apache.org>

>Are you in some kind of evil parallel universe? :)


Maybe not evil, but definitely alien ;-)   The problem turns out to be the
way in which the Tru64 Unix Bourne shell interprets "$@".


The ant startup script ends with

  ... org.apache.tools.ant.Main $ANT_ARGS "$@"


Under the Tru64 Bourne shell, "$@" gets counted as an argument even if $@
evaluates to null.  This is the source of the null target request that I've
been seeing.  None of the other Bourne shells that I've tried (Linux, AIX,
and Solaris) behave in this way, so I guess it's a Tru64 quirk.

For Tru64, removing the quotes around $@ in the ant script seems to fix
things.  Another fix is to change the ant script to run under ksh instead
of sh.

First possibility is; did you run 'ant' to build Anteater, or did you use the provided 'build.{sh,bat} scripts? Please always use the latter.

Anteater's build process uses a Saxon extension function to split up the XML manual into chapters. JDK 1.4 comes bundled with Xalan, which seems to cause this problem. Reported solutions involve removing Xalan from Java's lib/endorsed directory. Alternatively, just avoid the 'dist' target, as by default, the build script won't try to build the docs.

Sadly there is already a project on Sourceforge called Anteater. AFT stands for 'Ant Functional Testing'.