How I stopped worring and learned to love the Maven

For many years I was convinced that Maven was a plot to bring the community of Java developers to the point of extinction. It is very slow in development, overengineered and imposes a set of standards where a 20 line build script would suffice.

On the other hand I was always envious of the way Maven manages dependences and downloading 20 megs of dependencies every time I do a fresh checkout was a bit of a embarrassment. Well, last week it all changed.

What happened is that Kristian Rosenvold contributed a JavaRebel plugin. Him being a fan of Maven and me being a fan of JavaRebel we wanted to find some way to set up a Maven repo for various JavaRebel projects that wouldn’t expose me to the things I consider unholy. Lo and behold, the Maven guys have figured out our pains and provided the nifty library called the Maven Ant tasks.

Now this maybe ancient news to the Maven community, but being a hardcore Ant hacker I have always thought that Ivy is the best and latest in the Maven-Ant integration game. Ivy does the job, but it is a pain to configure and even after three years still very buggy. The Maven Ant tasks can use the standard Maven pom.xml files if you like them, or to configure everything in Ant if you don’t.

The basic gist is that you put the following three lines in your build script:
[xml]



[/xml]
This gives you a path dependency.classpath that includes all your dependencies and that you can refer as pathref or classpathRef. It is also possible to get a fileset of dependencies as well as individual dependencies using properties of the form ${groupId:artifactId:type}.

With the dependencies in such a form it’s trivial to use them even in existing build scripts. You just replace your current paths and sets with the Maven ones an voila — you get a hackable Ant script with all the pleasure of Maven and without any of the pains.

Tags:

This entry was posted on Thursday, November 20th, 2008 at 9:04 pm by Jevgeni Kabanov and is filed under creative. You can follow any comments to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.

  • http://www.codecommit.com/blog Daniel Spiewak

    I’m slowly becoming a fan of Buildr, the Ruby-based drop-in replacement for Maven2. For one thing, the syntax is great (three lines instead of fifty to get a basic Java project up and running). It also lets you drop back to Ruby whenever you need a Turing Complete language (that’s part of what drew me away from Ant).

    It is also *blisteringly* fast. I don’t know what it is about Maven which causes it to take so long on simple stuff, but whatever the problem is, Buildr avoids it. It isn’t perfect yet (still has some issues with weird Maven repo layouts), but it’s getting there.

    Oh, and thanks to the efforts of Nathan Hamblen, it also has support for JavaRebel: http://www.javaworld.com/javaworld/jw-12-2007/jw-12-outside-the-ide.html?page=4

    I still use Ant for most Java stuff, but I have completely switched to Buildr for Scala, and I’m definitely leaning its direction for just about everything else. Should be interesting to see how this “war of the build tools” shapes up and which one ends up reigning supreme.

  • http://technically.us/code n8

    Wow, that’s the most props I’ve ever gotten for a single method call! But with Buildr it’s all about example code (otherwise goodbye weekend afternoon) so I guess that counts for something.

    The first thing I thought when reading this (I hadn’t heard of it) was that Buildr also could get to Maven dependencies through Antwrap. That would be super-slow, but could be useful for pom.xml migration, or even (cached) transitive dependency support. Maven would be the de facto standard for resolving dependencies (with all its ambiguous cases, quirks, bugs, whatever) that other tools could call into rather than try to emulate.

  • Taisa

    The 2 biggest problem I have with maven is sometimes it’s difficult to resolve library dependencies using the maven-dependency-plugin and dfining more complex tasks require you to either write a plugin or call and Ant task wchi is pretty nuts(since I don’t believe xml is a programming language). Ivy is more functional in the aspect that’s one of the reasons I’ve been trying out Gradle, a build system that uses Ant, Ivy and allows you to define tasks with groovy. The other reason is groovy is much closer to java than ruby and co, so my programmers don’t need to learn an entire new language to modify a build script.

    I think it’s almost ready for serious use(probably around v0.6 or 0.8) but in the meantime were sticking with maven which has been pretty good.