Dependency Management with Ant and Ivy

One of my long-standing complaints with Ant is that project dependency management is non-existent in the core Ant distribution. Many will quickly point to the Maven Ant tasks, but I’ve never been really fond of them for one reason or another. The other advice I often get is to use Ivy, but even after several attempts, I had never gotten Ivy to work. With the recent release of 2.0 beta 1, though, I thought I’d try again, and I’m glad I did. Not only have I gotten it to work for me, but I was also able to successfully configure custom resolvers. Below is what I had to do to migrate the Mojarra Scales dependency management to Ivy.

Using Ivy requires, at least in the way I’m using it, two new files, ivy.xml, which defines my dependencies, and ivysettings.xml, which configures my custom resolvers. The usage from my Ant build file is actually pretty simple, so we’ll start there:

You will also need to define these properties somewhere:

But what’s going on here? The -download-ivy target, simply downloads the Ivy jar and installs it in the target directory, lib/build in Scales' case. Next, -install-ivy tells Ant how to find the Ivy tasks. Finally, in the update target, we tell Ivy where to find the settings (which we’ll look at in a moment), and then we tell Ivy to download the dependencies.

But what’s that pattern all about? This, I think, is a pretty interesting aspect of Ivy. Unlike Maven (and the related Ant tasks), the files aren’t just downloaded into a local repo and left, exposed to the build system through some sort of path or fileset reference. Ivy does download and cache the artifacts, but it also copies those to a directory in one’s project (at least, that’s how I have it set up ;). The pattern tells Ivy to copy the files a directory named after the configuration (more on that in a moment) under the lib/ directory, using an artifact-version.ext file name structure. It is then up to me to create a classpath or fileset reference from those files, and I think I like it that way. So, what’s this "configuration" I mentioned? For that, let’s turn our eyes to ivy.xml.

The ivy.xml for Scales looks like this at the moment:

Let’s take that one section at a time. The first element we see is info, and I’ll be honest here: I’m really not sure what that’s for at the moment. I think it may be related to publishing (or installing, in Maven parlance) project-specific artifacts to a repository somewhere, but don’t quote me on that. The next section is where we define "configurations," which seem to be roughly analagous to Maven’s scope’s, but completely configurable and arbitrary. I have defined five configurations:

Take note of the extends attribute. It works just like you probably think it does: since compile extends applet, it will get all of the artifacts defined for it, as well as those defined for applet. Given how Ivy (is configured to) handle dependencies, that means you’ll get two copies of some of those artifacts, but I’m OK with that.

Next in the file is the list of dependencies, which is pretty straightforward. The org maps to Maven’s groupId, the name maps to artifactId, rev maps to version, and conf maps to scope in Maven terms. Please don’t ask what that odd "→*" is there for, as I don’t understand that fully yet. All I know is that it won’t work without it. :)

Next up is ivysettings.xml:

One of the great things about Ivy 2 is that is configured to look at Maven repos by default. For Scales, though, I need some artifacts from the java.net Maven repository. To enable that, I have to define a custom resolver, which we see in the resolvers/chain elements. The chain resolver instructs Ivy to try one resolver after another to find the current artifact, with the returnFirst attribute telling Ivy to bail out as soon as a resolver that locates the artifact. Inside the chain, I instruct Ivy to use the ibiblio repository first. I then configure both the Maven 1 and Maven 2 java.net repositories. To do that, I configure additional instances of the ibilio resolver, but I change the root URL for the repository. In the case of the Maven 1 repository, I describe the pattern needed to find the artifact, as well as telling the resolver that the repository is not Maven 2 compatible. Finally, I create a URL repository, called "sourceforge," which I will use to resolve my YUI dependency.

With all of that in place, I can issue an ant update from the command line, and sit back and watch Ivy checking the configured repositories for my dependencies. It may seem like a lot to configure for dependencies, but Ivy is certainly better than the homegrown dependency management schemes I’ve seen (and devised), and is certainly less intrusive than migrating wholesale to Maven. While I <i>am</i> coming around on Maven 2, this will be a great tool for those projects that I can’t (or won’t) migrate.