Tutorials : Using Ant and CVS for multi-developer projects :

Using Ant and CVS for multi-developer projects

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

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

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.