sampa : colin’s blog

Now that Ivy 1.0 is out, I’d strongly encourage every Java developer to pull it down and consider using it to manage dependencies in their Ant builds. As far as I’m concerned, it’s a complete no-brainer.

Ivy does one thing, manage dependencies, and does it quite well. What’s nice is that it has a decent set of defaults, so starting to use it is trivial, but the model is also powerful enough to handle declaring and managing dependencies for complicated multi-project builds.

If you have typical simple Ant build with one project with a lib dir with a bunch of Jar files in it, then getting rid of those baked-in jars (from CVS) and having Ivy instead pull down (with caching) the jars you need (along with all their transitive dependencies) can be as easy as adding the following to your build file:

  <target name="resolve">
    <ivy :retrieve/>
  </target>

and creating an ivy.xml file describing your project dependencies:

  <ivy -module version="1.0">
      <info organisation="mycompany" module="mycomponent"/>
      <dependencies>
          <dependency name="commons-lang" rev="2.0"/>
          <dependency name="log4j" rev="1.2.8"/>
      </dependencies>
  </ivy>

While everything is pluggable, in a default setup like this, Ivy will pull down your dependencies (i.e. Jar files), as declared, from the well-known iBiblio repository. It will also look on a parallel ‘IvyRep’ repository for optional ivy.xml files describing the dependencies of those dependencies, so that in fact what you retrieve is a transitive closure of all your dependencies and their dependencies, and so on.

The important thing though is that while simple cases are easy to handle, and there’s immediate value, the Ivy dependency model is powerful enough to handle pretty well any complex multi-project dependency setup. Considering all the hand-written, adhoc dependency management XML code I’ve had to do in Ant builds for multi-projects applications over the last 5 years, I would have killed for something like Ivy. (Never mind all that wasted space in CVS duplicating dependencies; iBiblio aside, there’s often a value to having dependencies in CVS somewhere, but ideally this is in a shared location accessible by something like Ivy, not duplicated in every project as is typically done).

Here’s a nice XSLT generated HTML view of an XML Ivy dependency declaration file which shows to what level you can take things. Basically, any module can declare a set of configurations which specify what external libs are needed (along with their transitive dependencies) for those configurations, and then the module can declare what artifacts it publishes itself, and what configurations are needed for those. Artifacts can be retrieved from multiple, pluggable, repositories and module artifacts when generated can be published back to those repositories to handle integration builds for example. It’s also possible to generate a nice report of the actual dependencies resolved for a module (also check out this variant shown graphically), or a nice view of all the libraries available in a repository

Give it a try, I don’t think you’ll go back to manual dependency handling! Ivy is BSD-licensed, by the way, meaning it should be usable anywhere.