Development Tools

Recent articles:

Popular archives:

JUnit best practices (2000)
Java design patterns: Simply Singleton (2003)
Hello,OSGi: Bundles for beginners (2008)

Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can, or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing heavily in Java's future as a platform for platforms

Also see:

Discuss: Tim Bray on 'What Sun Should Do'

Featured Whitepapers

Incremental and fast builds using Ant

Enable your Ant builds to perform faster and more optimized builds

By Arin Ghazarian, JavaWorld.com, 11/07/05

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

A good build tool and process should not perform needless and redundant time-consuming work on unchanged sources each time the build runs. In other words, it should only do the work required to apply the results of the source modifications to the build artifacts. If your build tool or process doesn't exhibit this behavior, then think about optimizing your builds by avoiding the needless work.

For example, assume we have a bottom-up build process—our project is built from a persistency layer up to higher layers. Usually, these kinds of projects have long builds caused by the code-generation and reverse-engineering tools used in them. As illustrated in Figure 1, first, the build process runs a SQL script on a database management system (e.g., MySQL) to create the database and fill it with sample data. Then, the Middlegen task runs to generate CMP (container-managed persistence) entity beans. Then the XDoclet task runs to generate remote, local, and home interfaces, value objects, and deployment descriptors for the CMP entity beans generated in the previous step. (For more on XDoclet and Middlegen, see Resources.) Next, this generated source code plus developers' written Java source code are compiled, and these compiled class files plus other resources are packed in jar, war, and ear files.

Figure 1. The sample build steps and outputs

Now assume that a developer working on this system's source code has slightly modified an if-else block and wants to see the results of his change. So he does a rebuild. A clean build erases everything generated by the previous builds and builds everything from scratch. For the developer, that means minutes of waiting and standing idle for a simple recompilation of the modified class and then an update of the relevant jar or war file.

In this article, I introduce some techniques to save you time by preventing redundant rebuilds of up-to-date sources and doing faster builds on outdated sources.

Continuous integration

To begin our discussion, let's consider continuous integration, the strategy of ensuring that changes to the project's codebase are built, tested, and reported as soon as possible after they are introduced. This reduces the costs and time needed for development teams' integration sessions. This process requires:

A source code control system like CVS so you have a central location for maintaining your code
A fully automated build and test process (e.g., using Ant)
An optional but highly recommended continuous integration automation tool like CruiseControl

Let's look at the overall picture (illustrated in Figure 2) of a development team utilizing this discipline and the activities developers do in such teams. Each developer has a local working copy of the project. Before starting the new task assigned to him/her, he updates his local copy with the changes committed to the codebase, accomplishes the newly assigned task (changes some portions of code, for example), updates his working directory with possible changes during his development session, does a build, executes the tests, and, eventually, if all tests execute successfully, commits the changes to the codebase.