This is a reference for setting up a new Ant-based Java project. It
contains most of the little Ant tricks I've learned over the
years. When I start a new Java project I clone this repository, remove
sections of build.xml that I don't care about for that particular
project, set the project properties, clear out the sample sources, and
get to work.

Building this project requires that Ivy be available to Ant. All you
need is ivy.jar in Ant's classpath (in your $CLASSPATH, $ANT_HOME/lib,
or ~/.ant/lib).

You will need to have Astyle installed and in your path for the
"format" target to work. If it's missing, that's fine. It won't affect
any other targets.

Ant will be looking for Checkstyle if you try to use the "check"
target. Like a hardcore bureaucrat, Checkstyle will harshly criticize
any stylistic mistakes and missing documentation, requiring you to dot
every "i" and cross every "t". That can keep idle hands pretty busy.

Ant will be looking for ProGuard if you try to use the "optimize"
target. This tool does a bytecode analysis to shorten (and obfuscate)
identifiers and remove unreachable code.

There is a "hotswap" target for replacing live code while an
application is running. You'll need the hotswap Ant extension
installed to use it. This target is to be used alongside the
"run-hotswap" target, which enables hotswapping in the JVM. You can
demo this for yourself by running "run-hotswap" in a terminal, editing
the printed string in the code, and running "hotswap" in another
terminal. The printed message in the running program should change to
the new string.

Note that ProGuard, hotswap, Ivy, and Checkstyle are needed only in
the build classpath, not your project's classpath. That means you
probably don't want them in lib/. They should be where Ant can get to
them, not your project.

Take note of the sample pom.xml file. This is not actually for Maven
builds -- this is an Ant project afterall -- but for publishing builds
for a Maven repository. It's packed up by the "bundle" target, which
creates a bundle.jar containing your project's signed artifacts. To
use the "bundle" target you need to have GnuPG set up in your path, a
generated key pair, and a running gpg-agent, unless you like typing
your passphrase a bunch of times in a row.

I hate coding absolute paths in my build script and I hate including
built files as part of the base project. My philosophy is that the
*environment* should be set up so that the tool can easily find the
external resources they need (JUnit, etc.) from the system, not within
the project. It's the system or dependency manager that provides the
libraries. Anyone who has the proper development environment set up --
one that works across many projects -- should be able to clone the
repository and do a build simply by running the build program with no
special arguments. There should be no need to edit or install anything
into the project space for the initial build.