Software Development Build Management

As a rule, a version control repository should not contain any files that can be reproduced by the build process. Examples:

• Java class files
• Temporary directories used by the build should be created by the build process (and cleaned up by a 'clean' target)
• Property files that were tokenparsed
• Jar files of application builds
• Snapshots of the application source

Depending on how we do our builds, thirdparty libraries could also fall under this category. For example, Maven uses a shared repository for library dependencies. The personal preference of your build manager so far has been to keep a project's library dependencies in two directories: lib/thirdparty and lib/build-only. The former contains all libraries that should be packaged as part of the ear/war distribution archive. The build-only directory contains all libraries that are part of the application server (such as any J2EE libraries needed for compilation).

The main build file should be located in the root of the module. When checking out the module from version control, invoking the default target on this build file should not cause any errors. Typically, the default target should compile the code and assemble the war/ear file for deployment, but not deploy it. A good guideline for standard targets that can be common across all projects:

• core — default target; depends on ear or war, whichever is appropriate.
• clean — deletes all temporary directories created by the build; the result of this target should be that the working copy is identical to a newly checked out copy of the module (with the exception of changes made manually since checkout).
• compile — creates the classes if necessary and compiles all the java code from src to classes.
• war — creates the war file. Depends on compile.
• ejbjar — creates any EJB jar files. Depends on compile.
• ear — creates the ear file. Depends on war.
• deploy — deploys the application.
• undeploy — undeploys the application.

All properties that are necessary to run a successful build, but varies from developer to developer, or from environment to environment, should be defined in property files. The build.xml file should respect the following hierarchy in overriding properties:

1. developer properties (only development builds)
2. environment properties