This is an old post. I have long since moved on to Maven as described here

The JSecurity team had a recent discussion on whether or not to use Maven 2 or Ant+Ivy moving forward. At the end of the day, I didn’t really care that much about which system we used, but I had three requirements:

  1. JSecurity releases must be pushed to the Maven 2 repository for easy access by both Maven and Ivy users
  2. When executing a build, I want versioned dependencies automatically resolved and downloaded for the builder. This way things are ‘hands off’ and the JSecurity release .zip file doesn’t have to be 14 megs. Excluding dependencies would drop it to maybe 3 megs – much nicer.
  3. I don’t want to manage builds much at all. Anything that takes my time away from JSecurity coding or writing documentation is less than ideal. Whatever system we chose, I wanted to spend maybe 2 or 3 days at the most configuring it and then just leave it alone (but still have it be clean and flexible enough for inevitable changes down the road).

What was the outcome? We ended up choosing Ant+Ivy, but I’ve outlined how we came to our conclusions based on the above 3 requirements for anyone that might find this useful when making their choice. This represents why it was a good choice for us, and may not be the same reasons for you. Everyone is different – choose what works for you based on your needs and desires.

Satisfying requirements:

Point #1 is handled trivially by both frameworks, so no need to speak of that further.

Point #2 is is handled by both frameworks without any problems, but that’s not the whole story: With further investigation, we found Ivy’s dependency resolution process to be more elegant, which had great appeal to us after we found out about it:

For any given dependency, both Maven and Ivy allow you to also control your dependencies’ dependencies that are downloaded. These are called transitive dependencies. For example, if your project requires hibernate to build, and hibernate requires JTA to build, does that also mean that your project needs JTA to build? In most cases this is not the case, and either framework will allow you to do excludes as necessary.

But Ivy has something more that turns out to be very powerful, something they call “configurations”. Configuration xml snippets in the ivy.xml file are more or less what I call dependency “views”. For example, one configuration entry (view) can mean “for a hibernate test, only require a, b and c jars”, or a “for minimal runtime requirements, only require x and y jars.” Here’s the best part – other projects can depend on these views so they only download what they absolutely requre, allowing configuration of transitive dependencies across projects. Extremely powerful, much cleaner, and arguably ‘more correct’ for proper software configuration management.

Another area related to point #2 where Ivy won out for our team is that only Ant is required, which is pretty much ubiquitous in all Java environments. Maven not so much. Ivy is even less so, but our plain ‘ol ant script will download Ivy for you if you don’t already have it, make ant aware of it, and then kick off Ivy as normal. NO software installation beyond Ant. That is just fantastic as far as I’m concerned, since we don’t want to force Maven on end-users who want to build the project. You’d be surprised at how something like that can make or break potential users. This all goes back to the lowest barrier of entry for people who want to use our project. This stuff matters to us.

Point #3: Maven actually won out here because of its black magic. It is easier to set up a Maven project for starters because it has so much built-in to it, whereas a similar Ant+Ivy setup requires plain ‘ol Ant setup + knowledge of how to incorporate Ivy. It might take a day or two to set up Ant+Ivy depending on your familiarity with Ant.

Although this is a powerful benefit of Maven, I feel it is beneficial for only small or simple projects. If you have a moderately complicated build environment, or one in which any level of specific customization is required, its far easier to do with Ant instead of fighting with Maven’s black magic quirks. Once you spend the initial day or two getting Ant+Ivy to just work, you rarely have to touch it again.

Add in the big ant benefits of macrodef and import and you quickly get an ‘OO-like” build approximating what Maven can do. Yes it requires more effort, but when you can do what you want, whenever you want, well, I enjoy that piece of mind. I don’t want to fight with my build system when I need something – I want it to adapt to my needs.

In the end, it took me a couple of hours to set up Ivy and play with it and read the documentation and and continue to play with my ivy.xml “configurations” (views). But, now it is smooth sailing. I’m loving Ivy, and I’m glad that we made the choice we did.

– Les