3.12 Defining a Consistent Environment

3.12.1 Problem

You want to ensure that all developers on a team are building the project with identical configurations.

3.12.2 Solution

Ant buildfiles should be as self-contained as possible. Any reliance on external resources, such as the CLASSPATH environment variable, opens the door for different developers to have different settings.

3.12.3 Discussion

Without tools like Ant, different developers probably use different tools to compile their code. Some might prefer to work in text editors like Emacs, while others may use IDEs like IntelliJ IDEA or Borland JBuilder. Each developer probably has her own unique configuration in such an environment.

Regardless of which tools individuals use, every member of a project should be able to compile her code in a controlled manner before committing changes to a shared repository. Nothing is wrong with letting developers use the tools they are most comfortable with, but you should use a tool like Ant for a common baseline.

Here are some specific tips for setting up an Ant buildfile to ensure a consistent build by all developers:

The buildfile should not rely on any external CLASSPATH.
If the build requires third party JAR files, put the correct versions in a shared directory so each developer builds with the same versions.^[2]

^[2] We highly recommend you keep JAR files under version control.
The buildfile itself should be kept under version control.
Provide a "clean" target that destroys all generated code.

The clean target is essential because it ensures everything will be compiled during the next build. Ant relies on file timestamps to determine when class files are out of date with respect to source files. Although this catches most dependencies, it does not handle many semantic dependencies. For example, you might remove a method from a base class; the base class will recompile, but any derived classes will not. The compile may succeed (incorrectly) until you perform a clean build and find the problem.