TFS build automation for a Java project using Ant

In a previous article, I walked through the process of installing and using Team Explorer Everywhere on an Eclipse environment. That way, you can use TFS for your Java development. In this article, I will cover the process of how you can use the Team Foundation Build Automation to automate your Java builds using Ant. I’ll guide you through all the necessary steps and give you some personal experiences.

First of all, you need to have Team Explorer Everywhere installed (more about that in my previous post). If you have this, you’re ready to go.

Getting started with Java and Ant

To start, let me explain you what Ant is and how you can use it.

Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects. Ant stands for ‘Another neat tool’ and was released at first in 2000.

The Ant build definitions are declared in a build.xml file. The root node of a build.xml file is ‘project‘, where you define the name of the project and the default ‘target’. This target will be executed when you build your project. The child-nodes of a project are those ‘target‘ definitions. You can define as many targets as you want. For example ‘clean’, ‘compile’, ‘jar’,.. Each target can have its dependencies. You can define that the ‘jar’ target depends on the ‘clean’ and ‘compile’ target. That way, you have a sequence of executing. Let me give you a really basic example:

http://www.alexandervanwynsberghe.be/wp-admin/options-general.php
[/xml]

When you use Eclipse, you can use the Ant window to visualize the Targets of your build.xml file. (Link your build.xml file using the ‘add build files’ button) Using this window, you can also execute a specific Target by double-clicking on it. Be sure that you do a check-in of your build.xml file!

Create a build definition

Now you have Ant up and running, we can define our TFS build definition. This build definition will take care of the build process on our TFS build controller. If you want to learn more about build controllers and build agents on TFS, take a look at this article.

1. Open the Team Foundation Server Explorer in Eclipse (using the Team Foundation Server Explorer perspective). Select Builds node, right click and select ‘New Build Definition’

2. In the new window, the first thing you have to do is provide a build definition name and a description

3. The next step is to define the build trigger. Choose the option that suits you the best. In my case, I selected a Continuous Integration Build.

4. The following step is the definition of your working folders. This is the mapping that the build server will use. (If you defined a custom workspace mapping on your local machine, you can also copy this using the ‘Copy Existing Workspace’ button.

5. Select your build controller and the place where to output your files. Note that even on Linux, if you use a network location, use ‘\location’ and not ‘smb://’ (which you would normally use on a linux machine to access a Windows share). That’s because the build-controller is running on a windows machine, and this controller uses the network path you define there.

6. On the ‘project file’ section, you can define which ‘build’ you want to use. Click on the ‘Create’ button to start a new wizard. The first step in this wizard is to select which build file you currently have. In our case this is an Ant build file. Select this an click next.

7. The next step is to select your build.xml file, which is already in your project. Click finish to close this wizard.

8. As you can see now, the wizard tells you that there was a MSBuild project file found. That file was automatically created by the previous wizard. Note that this file is located in a folder called ‘TeamBuildTypes’. If you want to understand what’s in that TFSBuild.proj file, take a look at this document.

8. The last step is to define your Retention policy. There you can select some numbers of how many files are kept when a build succeeds, fails,..

9. Click Ok to create your Build Definition. You Should now see your new build definition in the list.

Build server changes

To summarize: We have a Java project, an Ant build.xml, a TFS build definition based on the Ant build file. The next step is to prepare our TFS Build server so it will be able to build Java projects based on Ant/Maven2. For that, you will need the Team Foundation Server Build Extensions Power Tools. They can be download here. This extensions provide the ability to execute Ant or Maven 2 builds from Team Foundation Server and publish the results of the build along with any associated JUnit test results back to TFS.

After you have installed this on your build server, be sure that you have the correct JDK and Apache Ant installed. Next thing you may not forget is set the correct environment variables to your (build) system. I spend quite a while looking for the correct one, so here they are:

Add a system variable ‘ANT_HOME’ with value ‘C:Program FilesWinAnt’ (or where Ant is installed). Next add a system variable ‘JAVA_HOME’ with value ‘C:Program FilesJavajdk1.6.0_25’ (or again where your jdk is installed). The last step is to edit your system variable called ‘Path’. At the end of this value (it should already contain a bunch of other settings) you add ‘;%JAVA_HOME%bin;%ANT_HOME%bin’.

Now you’re ready to go. The build server can now execute Ant builds.

Ant build usage with TFS

The nice thing about using Ant with TFS is that the TFS build will provide some extra parameters that can be used in your build. For example you have BinariesRoot, BuildDefinitionName, BuildDirectory,… You can use this parameters in your Ant build definition.

I’ll combine the previous explanation with the fact that you also have ‘conditional’ parameters in your Ant build file. What I mean is that you can declare variables, depending on the fact that the variable is or isn’t defined. For example, if you run your Ant build inside your Eclipse, you have no ‘BinariesRoot’ variable available. That’s because this is provided, additionally, by our TFS build script. What we  can do is the following:

<condition property=”dir.output” value=”${BinariesRoot}”>

<isset property=”BinariesRoot” />

</condition>

<property name=”dir.output” value=”${basedir}/output” />

So if the ‘BinariesRoot’ variable exists, then use it, otherwise use the ‘basedir’ instead. That way, you can create your Ant build so that it does run local, but also on the build server.

Run your build

Now you have all the parts completed, it’s time to execute your build. Using your Team Explorer in Eclipse, right-click on your build definition and click ‘Queue new build‘ (or do a code check-in if you defined a CI build). Now you should see the build running in the ‘Build Explorer Window’. Double-click on the build to see the results. You also have a log, containing the output of the Ant-build. If you go to the drop folder, you should see your output files.

Now it’s up to you to change your Ant build file, and play with some targets. In a next post, I will explain how you can define JUnit-tests in your Java application, and also link the results to your TFS build, and even watch the results in Visual Studio.

Thanks for reading!