News

Adding a build process

• By Dwight Deugo
• August 21, 2003

In the early days of Java application development, life was pretty simple. You would write your classes, compile them, put them in a package and send them off. Then came JAR files, an easier way of packaging, shipping, and locating class files and their resources. However, generating an application today is far more than just compilation and packaging. You have to write the code, compile it, generate documentation, gather statistics, test, package, deploy and sometimes generate more source code to feed the previous steps. Life is getting so much busier for the average developer. There is just much more to deal with.

One way to deal with the increased complexity and the number of things to do is to create a list for yourself and make sure that you follow it religiously. Perhaps you have read my comments on testing before. This step is not to be left out. However, this solution can create its own problem -- not with the list itself, but with the fact that we are human. We forget one or more of the steps occasionally, and something remains undone.

An improved solution begins with recognizing two things. The first is that you are defining an end-to-end build process that takes pieces of software through a complete build, test and deploy cycle in one go. You have to retrieve source from a repository, compile it, test it, generate reports, notify people of problems or success in the build, generate reports, generate more code and then deploy. The second important thing to recognize is that if you attempt to do these tasks manually, you will make a mistake. A better solution is to automate the entire process because you can standardize the process, repeat the process, reuse the process, understand the process and demonstrate the process. In addition, you can ensure that the process is done fully, without omission, every single time. The benefits are time, money and quality. You should save time and money because anyone can initiate the process and benefit from the knowledge, such as classes, classpaths and test cases that are defined within the process. And you should be able to increase the quality of your software by guaranteeing that every build meets the same requirements, such as passing test cases.

I am always surprised to find that many developers have not heard of Ant, a great open-source tool that was developed for the specific purpose of automating the build process for Java applications. Everything you need to run Ant can be found at ant.apache.org/. Ant is itself a Java application like Make. It is a command line tool the uses a build file, an XML file, to describe the tasks it needs to execute as part of the build process. It is up to the user to create the build file. However, once that is done, you can run it again and again and again. You can also share this file with others that have Ant installed on their machines, so that they can run the same process. Ant is also integrated into many IDEs, such as Eclipse, which each provide a GUI interface for running Ant but are still based on the notion of a build file to define the tasks for the process. Many people might think of Ant as an IDE, but it is not. It is just a tool to manage the activities of a build process, such as compiling and producing a JAR file.

-- The following is an example of an Ant build file that is the starting point for most users:

<?xml version "1.0" ?>
<project name="YourProject" default="deploy">
	<target name="initialize"
		<mkdir dir="build/classes" />
		<mkdir dir="dist" />
	</target>
	<target name="compile" depends="initialize"
		<javac srcdir="src"
			desdir="build/classes" />
	</target>
<target name="document" depends="initialize"
		<javadoc desdir="build/classes"
			sourcepath="src"
			packagenames="org.*" />
	</target>
	<target name="deploy" depends="compile, document"
		<jar destfile=dest/project.jar"
			basedir="build/classes"/>
		<ftp server="deployserver.net" 
userid="jim" 
password="1q2w3e">
			<fileset dir="dist" />
		</ftp>
	</target>
</project>

In this build file, the initialize target creates two new directories: build/classes and dist. The compile task depends on the success of the initialize target. The compile target compiles all classes found in the src directory and puts the class files in the newly created build/classes directory. The document target also depends on the success of the initialize target and takes all packages beginning with org from the src directory and creates the javadocs for them in the build/classes directory. In the deploy target, which depends on the success of both the compile and document targets, a JAR files is created -- called dest/project.jar -- that is composed of the files in the build/classes directory. The contents of the dist directory are then FTP'd to the deployserver.net using the given password and userid.

To run Ant, you can type in Ant by itself and let the default target execute, which in my example is deploy. If you wish, you can be more specific and enter the target you want, such as Ant initialize, which will run only the initialize target. This statement is only partly true. Ant will also run all of the dependant targets that require executing.

What else can you do? Lots. Given the large number of tasks available with Ant, there is not enough room here to give a complete summary. However, you can go to http://ant.apache.org/manual/tasksoverview.html for an in-depth list. In short, here are some, but not all, of the high-level tasks Ant provides: Archive Tasks, Audit/Coverage Tasks, Compile Tasks, Deployment Tasks, Documentation Tasks, EJB Tasks, Execution Tasks, File Tasks, Java2 Extensions Tasks, Logging Tasks, Mail Tasks, Miscellaneous Tasks, .NET Tasks, Pre-process Tasks, Property Tasks, Remote Tasks, SCM Tasks, Testing Tasks, and Visual Age for Java Tasks. There are also many other tasks that individual developers and tools have created that are freely available.

In general, Ant will permit you to create a build file that allows you to perform just about every task you have done manually to create and deploy an application. If you can't find the task you need, you can always create your own, but that's another column. However there is more to building and deploying an application. Wouldn't it be great to be able to support multiple projects and build files that can be manually or automatically initiated from major version control repositories with e-mail notifications for when things have completed or failed, and using the Web to manage it all? If you answered "Yes," the solution is Anthill OS.

Anthill OS is a freely available project tool from www.urbancode.com/projects/anthill/default.jsp that ensures a controlled build process along the lines I just outlined. There is also Anthill Pro (http://www.urbancode.com/products/anthillpro/default.jsp), which has even more features, but you pay for this version. The choice is yours. However, each one is a build process constructed on top of Ant. If your Ant build file worked for you standalone using Ant, it will also work the same way with Anthill.

Regular building, testing, documentation and deployment are the key ingredients to a successful application. If completed by an individual, some items may be neglected. But by adding them as part of an automated process that runs continuously, they can't be ignored. Make Ant part of your build.