The amazing adventures of Doug Hughes

Here at Alagad, we are in the business of not only writing code, but developing and deploying enterprise class applications. Doing this properly involves a lot more than just writing ColdFusion, Flex, etc. code. When developing an application, we have distributed development environments, a testing/staging area, and a production/release area. We use Subversion for source control and a variety of other testing tools. One of the problems that comes up with a situation like this is how do you get code out of Subversion, to the development environment, then to testing and production while maintaining the integrity of the application and all of its configuration?

The answer I have always given other developers when asked this is something called ANT. However, I have never really used ANT myself and have never really explored under the covers to see what is really possible. The point of this posting and several more to come is to take you along on my journey into all that is Apache’s ANT.So what is ANT?When you write code in languages like Java or C, you must run a separate compile/build process afterwards before you can actually deploy the code. With ColdFusion, this is handled for us under the covers and we don’t have to worry about it. There are a variety of tools out there for compiling and building applications, but they are typically platform dependent and not the most user friendly. So, one day, Mr. James Davidson, a Java developer got tired of this situation and wrote his own tool which he called Another Neat Tool, or ANT for short. ANT started out being used by several Apache Jakarta projects and quickly spread through the Java developer community and beyond, becoming the standard for automating the build and deployment process for software projects.

ANT is written in Java, so it is platform independent and easily usable for any developer. ANT makes use of XML based build files which provide the instructions for what the ANT deploy process is supposed to do. These XML files can be created and managed in any XML editor and are easy to use and validate.

Installing ANT

ANT can be downloaded from the Apache site at and there are a variety of package types to choose from, although they should all end up with the same result based upon your OS. After you have “installed” ANT – it was just a matter of unzipping it for Windows – there are a couple of other things you need. First off, you need a Java JDK – at least version 1.2 and 1.5+ is currently recommended. According to the documentation, the higher the JDK version is, the more features of ANT you will have at your disposal. Once you have ANT and the JDK, you will need to add the file path to the BIN folder inside of the ANT folder to your class path. You will also need to create two environment variables – one called ANT_HOME which points to the ANT folder and one called JAVA_HOME which points to your JDK. For my setup on Windows, these paths look something like this:

  • Add to path: C:Apache-ANTbin
  • ANT_HOME: C:Apache-ANT
  • JAVA_HOME: C:j2sdk1.4.2_15

Once all of this is done, open up a command line and type: ant -version. The result of this command should be a single line with the version number of ANT that you installed. If you get any other error messages, the most likely issue is that one the environment variables above is not set up right.

Now What?

Now that you have ANT installed, what do you do with it. First off, I setup a simple little build.xml file just to make sure ANT was working. The contents of this build.xml file looked something like this:

<?xml version="1.0"?>
<project default="help" name="demo">
    <description>Test build.xml</description>
    <target description="usage information for common tasks" name="help">
        <echo>usage: ant [target]</echo>
        <echo>typical targets: init, dist, deploy, clean, help

Save this XML snippet as build.xml. Then at the command line, make sure you are in the same directory as the build.xml file you just created and type ant. If everything works correctly, the result should look like this:

Buildfile: build.xml

[echo] usage: ant [target]
[echo] typical targets: init, dist, deploy, clean, help

Total time: 0 seconds

What we have just done is create the ANT equivalent of a Hello World script. The <echo> tags simply display the text contained back to the command line

Looking Ahead

Now that I have ANT setup and running, I have to go do some more digging as to the syntax and possibilities for the build.xml file. As soon as I have more, I will post it here. Some of the things I am looking to do with ANT include:

  • Add and remove files from a Subversion repository
  • Remove all of the junk *.svn files from my code base before deploying the code
  • Run cfcUnit and Selenium tests on my code
  • Move the code to a testing or staging server via FTP
  • Update datasource and other path settings when the code is published to a different server
  • Run SQL scripts on a database to initialize it or set it to a specific known state

I have a handful of ANT resources I am currently going through, but if you have more, feel free to post them as I am sure I am not the only one that will benefit. Until next time …..

Comments on: "Better Development Practices with ANT" (2)

  1. Mike Henke said: – has examples for most of what you mentioned in the looking ahead section.


  2. John Paul Ashenfelter said:

    You could start with this old article I wrote for (shudder) CFDJ

    As an aside, the way to remove all of the “junk” .svn files from your code base is to do a svn *export* command. That gives you a clean copy of everything.

    dbUnit is probably what you want to look to for dealing with manipulating the database

    I cover most of this in my Ant and dev process talks at CFUnited fwiw.


Comments are closed.

Tag Cloud

%d bloggers like this: