The Path to Zen

Ivy has lots of potential

Having recently been severely frustrated by that other ambitious Apache project that aims at “making the build process easy”, and “providing guidelines for best practices development”, etc. - OK, who am I kidding? Yes, I’m referring to maven 2. - I turned my eyes to Ivy, and, after a couple of week of using it, found myself comfortable enough to write this to recommend Ivy as an indispensable part in any serious Ant-based build tools arsenal.

What do I like about Ivy? Well, let me start with the fact that it doesn’t try to reinvent Ant, but rather serves as an extension to Ant (and can also run stand-alone outside any Ant context). It is essentially a dependency management engine - it focuses on being a good one at that, and once dependencies are resolved and retrieved, it stays out of the way for the rest of the build process.

Ivy offers a powerful expression language for specifying a variety of version patterns. There can be patterns like “1.4.+”, which can be satisfied by any version later than 1.4, “[1.4,)", which means any version of 1.4 or after, or "[1.4,1.9], which selects any version between 1.4 and 1.9, including both.

The concept of “configuration” in Ivy also comes in very handy when you need to categorize the dependencies, and influence how classpaths ought to be assembled according to the different contexts they’ll be used in - e.g., I was able to define configurations called “build”, “test”, “coverage” to deal with dependencies required at build-time, test-time, and test-with-emma-the-coverage-tool-time.

Another strong selling point of Ivy is that it has built-in support to leverage the existing ibiblio maven repositories. Ivy’s ibiblio resolver works with maven 1 repository by default, but can be set in “m2compatible” mode with one attribute flip. The more universal URL resolver in Ivy can work with pretty much any repository structure whose paths are defined in patterns. Although for most practical projects, the out-of-box ibiblio support, combined with the cache resolver that tries to resolve artifacts in the local cache first, would suffice very well.

The one caveat I found out, though, is that at the moment the ibilbio resolver doesn’t handle the directory listing of some existing maven repository proxy tools, such as maven-proxy and proximity. So the dynamic version resolving (such as range or wildcarded version numbers) feature, relying on the resolver parsing directory listing to discover available versions, won’t work when there is a ibiblio resolver points to a proxy server. According to the developers, this issue is definitely on the radar and hopefully will be addressed by the time the next major version (2.0) comes out. Possible workarounds I’m contemplating on include setting up a reverse proxy with an internal apache server, or adding an extra Ivy resolver pointing to the internal repository. I’ll try those and report back.

As Ivy has recently been taken under the Apache wings, and become an Apache Incubator project, I hold high hope on its codebase maturing rapidly and eventually graduates to be yet another great Apache tool. I believe as far as build management is concerned, Ivy offers a great opportunity to leverage and combine the two valuable assets the Java community has built over the years - the mature Ant toolset and the sophisticated ibiblio maven repositories. As Colin Sampaleanu pointed out, the decision to use Ivy is a no-brainer.