« QOTD | Main | Serving up XML feeds from TextDrive »

Integrating Ivy with AntAnt to manage jar files

I've been using an Ant script to generate Ant scripts and build structures for over 4 years now. Given that all anyone does with Ant files is cut and paste from the last one they used, it seemed that a scripted aproach would help. I've been planning to put it on a public subversion server and open source it since forever, but never seemed to have had the time. The current incarnation of this tool is imaginatively called AntAnt. In no way is AntAnt comparable to a rich build framework like Maven.

AntAnt is a cross between what Michael Feathers calls a stuntwork and what David Heinemeier Hansson calls opinionated software. It does a single job, gives precious little options, and then gets out of your way. The single job is to generate a consistent build setup for your java projects and allow you to get on with coding instead of understanding what the last guy did. It doesn't have options for laying things out - you get what you get. Aside from time, the latter has been another reason I've never gotten round to open sourcing this; I always figured that everyone else would need a raft of configuration options and I frankly couldn't be bothered doing the work when the feedback came in. Personally, after 8 years of Java programming, the options I need for build setups are baked into AntAnt. I haven't changed the basic functionality and layout for a few years now. The last chunk of working was upgrading to use Ant 1.6, which cut out a lot of duplication out of the generated build files, and have the project layout play nice with Eclipse. Options and flexibility just seem to cause trouble in build systems.

The one thing it doesn't do, and I have always wanted it to do, is jar management - not so much dependency management but an answer to the question "should jar files go into source control or not?". Putting them in source control is great because you can checkout and build. Putting them outside source control is great because your repository will suddenly be 20% the size it was. It's pretty nasty when you checkout a project and find you can't build it because a sysadmin took the web server hosting your jarfiles away. It's pretty nasty when you checkout a build find you can build it, but it breaks in production because the project is depending on the head of another project for development and version 2.6 of the other project in production. My observation is as follows: developers want jar dependencies in source control and everyone else wants them anywhere but source control. One compromise for large multi-project repositories is to check the jars into a global lib dir and point the sub-projects at it. At least that way you'll only have one copy of servlet.jar checked in instead of six. AntAnt allows you setup a global lib area like this if you need it along with the usual lib folder for a project.

Looking around, it seems that Ivy might have an answer to this question. Ivy's claim to fame is primarily transitive dependency management in Java. But it also lets you declare a local file repository and/or a manifest of servers (ie ibiblio) to pull down jars into its repository cache. It works like Maven, but is easier to setup for the local file system case (imo) and easier to get it going with Ant (again imo, and yes I know about the Maven ant tasks).

So I just integrated with Ivy this afternoon, from following the documentation and how the WebWork2 code base uses it. AntAnt now gives you an ivy.xml and ivyconf.xml to set up and automatically treats any global lib area as a file based repository for Ivy. It seems to work ok and will cut out some duplication. Conclusion: Ivy is a great tool and I should have done this a year ago. [Business people would get much better software if we had 3 day weekends.]

I'll be going with Ivy+AntAnt, at least until Maven2 is wrapped up. Maven2 is looking much much better than Maven (here's hoping they throw out XML scripting entirely for the final release). But it's still a lot of overhead. About the only thing I might do is get AntAnt to generate the standard Maven project layout instead of my own, so people have an upgrade path to Maven (in Subversion this isn't so bad, but in CVS doing surgery on folder layouts is a nightmare). Irrespective of my opinions on the Maven the software, Maven the collection of idioms will probably dominate Java development from here on out.

October 2, 2005 04:34 PM


(October 3, 2005 01:32 PM #)

It's pretty nasty when you checkout a project and find you can't build it because a sysadmin took the web server hosting your jarfiles away.

As if I would... ;)