Using Ant and CVS for multi-developer projects
by Kief Morris kief@kief.com
Introduction
Managing source code and builds for a Java-based project can be difficult when you've
got a team of programmers working together. Choosing the right tools is a good first
step, but figuring out the best way to use them is an important next step. Just as
looking at the source code of open source projects is a good way to learn programming
techniques, looking at the build and source management techniques of open projects
like Apache's Jakarta can be informative.
Jakarta has dozens of programmers collaborating from around the world, and has
devised its best practices for managing Java projects over several years.
One of the first obstacles Jakarta Tomcat developers faced was the awkwardness of
using build management tools such as Make for compiling Java code. They answered
this challenge by developing the Ant build tool, which has rapidly become the
standard build tool for Java developers everywhere. Ant recently released version
1.5, which is available from the Jakarta
site. Jakarta source code, like that of all the Apache projects, is maintained
in repositories using CVS, which allows each developer to maintain their own copy
of the code, and ensures that merging changes between different developers is
handled sanely. CVS is available from the
CVS site.
Once you have these tools, you must set up your build process by writing a build.xml
file that Ant uses to compile and build your source code, and CVS project repositories
to share your code between developers. Each project should have a build.xml file
which is shared by all developers, and allows new team members to get started
quickly. But different developers may work on different platforms using different
tools, so writing a build file that accommodates everyone takes some special care.
As a development team grows and branches out into different projects, figuring out
how to handle common code and dependencies also becomes challenging.
This article discusses some best practices for handling these concerns, outlining
how to create a build system for your project which is both flexible and consistent.
The concepts described here were used to develop a complete, if simple, build.xml
file suitable for any basic Java project.
Writing configurable Ant build files
The latest version of Ant can be downloaded from Jakarta, documentation for
installing and using it is
available online.
Novice Ant users tend to put all of the information for a project into the
build.xml file itself. Below is a simple example of a build file which compiles
Java source into class files. Notice that it hard-codes the paths to the source
code and the output directory, as well as compiler options.
<project name="build1" default="compile" basedir=".">
<target name="init">
<mkdir dir="c:/projects/ourProject/build" />
</target>
<target name="compile" depends="init">
<javac srcdir="c:/projects/ourProject/src"
destdir="c:/projects/ourProject/build"
debug="on"
optimize="on"
deprecation="off">
<include name="**/*.java" />
</javac>
</target>
</project>
If your project is going to be built on different systems by different users,
they may want to change options, such as using different directories or compilation
options. You'll also need different options for your final build than your
development build, for instance disabling debugging. You could take care of this
by simply editing the file by hand, but then each developer will have a different
copy of the build file. If changes are made to build.xml which affect the way
the project is compiled, each developer has to reconcile the new version of
build.xml with their own configurations.
The way Jakarta projects such as Tomcat get around this is by moving
developer-specific configuration details into a separate properties file,
and then using those properties in the build.xml. Compare the first build.xml
with the one below.
<project name="build2" default="compile" basedir=".">
<property file="build.properties"/>
<target name="init">
<mkdir dir="${build.dir}" />
</target>
<target name="compile" depends="init">
<javac srcdir="${src.dir}"
destdir="${build.dir}"
debug="${debug}"
optimize="${optimize}"
deprecation="${deprecation}">
<include name="**/*.java" />
</javac>
</target>
</project>
This build file requires several properties to be defined in build.properties to
determine the location of the source files, the directory to put the compiled .class
files into, and compilation options. The build file can be checked into CVS, and
should not need to be changed to suit any particular developer's environment. Each
developer creates their own build.properties file, which is not checked into CVS,
and looks something like this:
build.dir = c:/projects/ourProject/build
src.dir = c:/projects/ourProject/src
debug = on
optimize = on
deprecation = off
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
