Welcome to Rotowatch

During the last week, I’ve been playing around with Maven and Ivy, trying to figure out which one would be better for moving our dependencies out of CVS.      For a small project or a prototype, I’m not really sure that a dependency manager is necessary.     It’s probably easier to just check 3 or 4 jars into CVS and move on.

For our main CVS module though, we have upwards of 80 jars in the lib directory.   11 of these are xdoclet jars, 11 are Apache commons jars, and 9 are different versions of JOSSO jars that are used depending upon what version of Tomcat or JBoss is being used.     When dealing with this many JARs, it begins to make sense to have something to keep track of these other than CVS.    Since we aren’t strict with our compile classpath (we just build off everything inside the lib directory), I think there could be potential situations where we might build successfully against an obsoleted API, but we break in runtime because we only deploy a specific set of JARs.

Maven has taken some getting used to.    I’ve started using Maven 2.0.    The strengths seem to be the project archetypes, which gets you going quickly with a specific project structure.    I’m not sure that I agree with all of the project structure decisions that were made with Maven, such as the fact that tests are split out into a separate source hierarchy as the classes they test.

I also feel like I’m giving up a great deal of freedom in how I lay out my project in using the Maven 2.0 archetype to generate my project structure.     For example, when I generated Hibernate hbm.xml mapping files this weekend along with classes, I started by putting them in the main/java tree until realizing that Maven would not copy the hbm.xml files unless they were in main/resources.    Makes sense, but seems like sort of a waste to have three separate package hierarchies in java, resources, and tests.

The strengths of Maven are it’s dependency manager though.    It is easy to find jars in the ibiblio tree - I can’t tell you how many times this weekend I googled “ibiblio maven <insert-jar-name>”, and immediately came up with the directory containing the jar I was looking for.     I can’t help but think that this could be even easier too though.     What would be sweet is to be able to cut and paste a directory listing of jars, and get back a <dependencies> tree for all of the jars that were parsed out.    It seems like writing that CGI would take a few minutes and would save a great deal of time.     The Maven Repo Search is pretty neat, but wouldn’t it be cool if it did Google Suggest style AJAX autocomplete, and generated dependency XML for you?    If I get a few spare minutes this week, maybe I’ll write one up like this.    It seems like it would be fairly straightforward.

Ivy, on the other hand, I had high hopes for but was disappointed in.    Maven does a lot of things - some of which I don’t need, and having a simple tool to manage dependencies sounded very attractive to me.   I was hopeful that I’d be able to wire it up and maybe avoid learning Maven 2 entirely.    I was very disappointed though.     Ivy has it’s own separate dependency library, and although it provides an ibiblio resolver, I couldn’t always get it to work.     The first task I tried to get it to work for was my ant task for autogenerating classes and mapping files from our database metadata.     I spent about a half hour trying to figure out how to get hibernate-tools.jar version 2.1.3 and couldn’t get it.     Apparently on ibiblio’s site, the hibernate-tools.jar is in the hibernate directory (see hibernate jar directory).     I couldn’t get any mix of dependency rev/org/name to work for this jar and they all seemed to resolve to
http://www.ibiblio.org/maven/hibernate-tools/jars/hibernate-tools-2.1.3.jar when I needed
http://www.ibiblio.org/maven/hibernate/jars/hibernate-tools-2.1.3.jar.    Ivy’s documentation blames ibiblio’s directory layout for problems like these.    I ended up giving up on this one and checking hibernate-tools.jar into CVS.    I’m sure that if I messed around with the ivy.conf I could configure a resolver to check for the correct pattern, but I’m just wondering why I have to jump through that sort of hoop to grab a jar out of what seems to be the most popular dependency library out there (ibiblio).

The improvement I’d suggest here is that Ivy should give you the opportunity to just define exactly where the jar is for situations like this and for other JARs that aren’t stored in any coherent directory structure (jta.jar for example).   How hard would it be for Ivy to provide an URL attribute which let me download a jar by force-feeding it a URL?    I know that libraries like to shuffle things around, but providing that sort of option seems preferable to me than having to configure the resolver to check for pattern strings it should already be configured to check for.

My next task is going to converting the small ant/ivy build.xml/ivy.xml over to Maven.    Since we’re already doing some of our packaging in Maven, it seems good to be consistent wherever possible, and also I’ll be able to remove that troublesome hibernate-tools.jar out of CVS.