Build Automation Series: Part 2 – Dependencies

In the last post in this series we created a simple build for our java project that cleaned and compiled the source code.

Next we want to be able to write automated tests using some java test automation framework. For now we will choose to go with Junit. To use Junit we would need to add the JUnit jar file as a dependency on our project. In the past I would of just simply downloaded the Junit jar myself and placed it within a lib folder of the java project and checked it in along with the rest of the source code for the project. A better approach however is to use a dependency management tool like Ivy.

Dependency Management: Ivy

To use ivy we:

  1. Download ivy (version 2.0)
  2. Create an ivy.xml file for the project
  3. Add ant tasks to our build.xml file

In our ivy.xml file we add our dependencies. By default ivy will look up a maven2 repository for the dependencies you add. If you goto http://www.mvnrepository.com and search for ‘junit’ (lowercase) you will see it find a list of results related to junit. Click on the junit >> junit link you will see it display all the binaries for junit that exist on the repository. Also on the page is the POM Dependency xml:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.5</version>
</dependency>

We use the POM Dependency information on ivy as the following:

<dependencies>
	<dependency org="[groupId]" name="[artifactId]" rev="[version]" />
</dependencies>

so our junit dependency looks like:

<dependencies>
	<dependency org="junit" name="junit" rev="4.5" />
</dependencies>

Dependency Management in the Build: Ant + Ivy

To retrieve the projects dependencies, we need to call ivy:retrieve. The first time we try to retrieve the dependencies ivy will try to download these dependencies over HTTP. These are placed in the lib folder of our project and they are also cached in a local ivy cache. So if we try to retrieve these dependencies again ivy will goto the cache and get rather than going over HTTP.

So we also add a target to our build that allows us to clean the cache if we need to. See the build.xml file with added.

Command line usage

One of the key qualities of our build is that it is IDE agnostic. Ant is our build tool and we need to be able to perform a build using ant only from the command line. To do this the following should be in place:

  1. Download Ant (version 1.7.1)
  2. Set ANT_HOME to location where apache ant was downloaded
  3. Add ANT_HOMEbin to your PATH

Should be able to execute ant -version from anywhere and see it report what version of Ant is installed.

To allow Ivy’s ant tasks to be used within your ant build file from the command line, we add the following xml to our build.xml.

<!-- set path so ivy will be picked up when using ant from the command line -->
<path id="ivy.lib.path">
   <fileset dir="../build-automation-environment/lib" includes="*.jar" />
</path>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
           uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path" />

Eclipse integration

Integration of the build with an IDE can be helpful at times. To integration ivy with eclipse, we add the download version of ivy jar to Windowns->Preferences->Ant->Runtime->Global Entries.

I have also created eclipse launchers that execute a specified target(s) on the build.xml file. These are located in the eclipse-ant folder and can be invoked from the top menu as shown below:

eclipse-launchers

Qualities of a Good Build

So far we are saying that a good build is:

  1. Automated
    1. IDE Agnostic – build is performed by some build tool (like ant) and is not tied to any specific IDE (like Eclipse or intelliJ)
  2. Repeatable
    1. Is capable of being build on different machines from source checked out from source control.
    2. Clean – this target returns the state of the project to what it was when checked out from source control
    3. Compile – this target is responsible for compiling all source code of the project in a consistent way.
  3. Flexible
    1. Dependencies are easily managed (easy to upgrade to newer version of dependency if need be)

Coming up

In the next post, we will add a few tests and add automated testing to our build

View the code

You can browse the code for this post online at http://code.google.com/p/build-automation-environment/source/browse/#svn/branches/build-automation-series-2.

The code can be checked out from svn following the instructions here http://code.google.com/p/build-automation-environment/source/checkout.

Advertisements

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: