Ant does __not__ mean an insect in this text; instead it is the name
of a platform independent build tool. Ant can be used for the same
purposes as [Make]: to compile project modules and to build release
packages.

When compared to traditional systems such as [Make], Ant has some
clear advantages:

* Truly cross-platform, written in Java.
* Compilation is very fast (compiler is only instantiated once, removing the need to do class loading for each module).
* Strict [XML] syntax means that grammatic errors are easy to catch.
* Ant supports most common tasks out-of-box, such as [JUnit] or [CVS].  Doing these tasks is very easy.
* Very powerful file inclusion/exclusion mechanism.

Ant does have some drawbacks, too:

* [XML] syntax was not meant to be human-readable.  For example, commenting is harder.
* Ant syntax is limited, meaning that for someone used to the expressiveness of Makefiles, Ant can feel very restrictive.
** This also means that if someone brings out a new Java compiler, you will need to write a custom task to handle that as well.
* Doing something that does not have a task can be troublesome, and usually requires a custom module to be written. You can use shell commands as well, but that means you become OS limited.
* Build files become larger.
* Does not handle other languages than Java.
* Code reuse is difficult.

Summa summarum, doing simple things in ANT is ''very'' simple.  Doing
moderately complex things is more complex than Make.  Doing really
complex things - well, Make can handle those.  But with ''great''
difficulty.

The complete Ant documentation, source code, and binary downloads can be found from
[The Apache Ant Project|http://ant.apache.org/].

There is now a [SampleAntBuildFile] for an example.

But don't forget __keep it simple__.


----
Let me comment on some assertions here:

__[XML] syntax was not meant to be human-readable.  For example, commenting is harder.__\\
XML is meant to be easy to understand, if not human-redable. There is no difficulty in commenting ANT tasks in the build file using <!-- XML comments >. Moreover, ANT tasks have meaningful names and attributes which make a build file easy to read if you know how ANT works.

__This also means that if someone brings out a new Java compiler, you will need to write a custom task to handle that as well.__\\
First, there are not so many Java compilers around and there are [a lot that are already supported|http://ant.apache.org/manual/CoreTasks/javac.html]. 
Also, writing an ANT task is really straight-forward if you know Java in the first place. 
Since new compilers do not come out every day, I dont see any issue here. Moreover, since it is an Open Source project, you can be sure that ANT tasks for new compilers will appear as soon as the new compiler is available.

__Doing something that does not have a task can be troublesome, and usually requires a custom module to be written. You can use shell commands as well, but that means you become OS limited.__\\

This doesn't differ from MAKE in that particular instance. And the ability to easily create new tasks and integrate them makes ANT much more flexible.

__Build files become larger.__\\
As in any source file that is not taken care off correctly. You can link build files together in a complex project and call one build file from another, so if build files are large, it is by choice, not by constraint.

__Does not handle other languages than Java.__\\
Although it is true that ANT is more Java-centric, you can do much more with ANT, and you are definitely not tied to Java. All you require is a Java Runtime to run ANT. 
As stated previously, you can create your own tasks should you need it, but there are a lot of tasks coming with the default distribution aimed at many other things such as [building a .NET project|http://ant.apache.org/manual/OptionalTasks/dotnet.html]\\

Check the [ANT tasks list|http://ant.apache.org/manual/optionaltasklist.html] for more.

__Code reuse is difficult.__\\
Which code re-use? Re-using a build file? Well..you cannot re-use a MAKE file either. Actually trying to re-use build files makes few sense unless all your projects have the exact same structure, in which case you can choose to either create a "master" build file, or "template" build files and use those and customise the properties of each build in a different property file that you feed ANT with.


__Apach Maven Integration__\\
If you're building a custom JSPWiki, you might leverage some code reuse of it's build.xml, while integrating Maven for management of third party jars, by consulting the MavenHowto.