Maven 2 vs Ant+Ivy: Our selection process

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

24 thoughts on “Maven 2 vs Ant+Ivy: Our selection process”

  1. Oooh. Why didn’t you guys use maven? :(

    Never mind though. As long as we maven users can pull out the jsecurity library from maven repo. :)

    Thanks

  2. Hi Joshua,

    The post already explains exactly why we didn’t choose Maven 2 and decided to go with Ivy. Did you read it? ;)

    But yes, it was critical that Maven users could access the JSecurity library from the public maven repo in either approach. They can do that (and obviously so can Ivy users), so all Maven and Ivy users should be happy :)

    Regards,

    Les

  3. “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.”

    If you are really worried about this, why not include Maven in your repository? The core is quite small.
    And plus, if everyone had this attitude, we’d never advance…

    “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 customisation 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.”

    I disagree with you here. Maven is hugely beneficial in large projects – large multi module ant builds are a nightmare to maintain.
    Specific customisations can be accomplished with Maven, especially with embedded ant tasks.
    Why would you have to do anything else once you get Maven setup? Assuming you use pluginManagement. And if you’re paranoid about being online, just setup a local project repository.

    See my take on it here:
    http://stubbisms.wordpress.com/2008/08/28/maven-is-to-ant-as-a-nail-gun-is-to-hammer-and-nails-you-need-to-move-on/

  4. @Antony,

    Thanks for the feedback – even though we disagree on some finer points, I appreciate your opinion.

    “If you are really worried about this, why not include Maven in your repository? The core is quite small.
    And plus, if everyone had this attitude, we’d never advance…”

    You’re right – this is definitely possible, although I hadn’t thought of it off the bat. In fact, this is what we do with Ivy too: If the user doesn’t have ivy enabled, we download it automatically, enable it, and then use it for further dependencies. But, the reason why we do it this way is because the Ivy team had a perfect example showing exactly how – I guess I haven’t seen any examples doing the same with Maven, so it wasn’t as easy I suppose.

    “I disagree with you here. Maven is hugely beneficial in large projects – large multi module ant builds are a nightmare to maintain.
    Specific customisations can be accomplished with Maven, especially with embedded ant tasks.”

    This is the crux of the whole Maven vs Ant/Ivy issue, and you make it sound misleadingly easy.

    In my experience, and those more experienced than me with Maven that I have communicated with, this is _NOT_ an easy thing to do – customizations are the bane of Maven’s existence, people get lost down the rabbit hole on this so many times.

    My point was that, unless starting with Maven from scratch, most enterprise products have quirky things specific to their build process that need to be executed. Customizing Maven to do these things with any degree of proficiency requires deeper understanding of Maven than would be needed of Ant in the same scenario.

    And, you haven’t addressed Ivy’s superior (and I might add more ‘correct’) dependency management.

    For these reasons combined, we stuck with Ant+Ivy, and true to my estimate, I only spent about a day or two setting it up, and I haven’t touched it in months.

    Thanks again for sharing your experience!

    Cheers,

    Les

  5. @Antony

    P.S. One thing maybe you can help me understand is how to ensure Maven works (easily) in custom directory environments.

    For example, look at one of JSecurity’s sample application’s source tree: http://jsecurity.svn.sourceforge.net/viewvc/jsecurity/trunk/samples/spring-hibernate/

    Since it is a web app, that directory tree is already laid-out _exactly_ as it appears during runtime. The only addition is the build.xml file that exists to compile the sources and build the .war.

    This is incredibly intuitive, and makes the build a no-brainer, since there isn’t copying things from an /etc/ directory, or moving things around to be in a the war format. How do I get Maven to work _exactly_ like this?

    I don’t want the Standard Maven Directory Layout to be used here (/resources/,etc), because for a webapp, its just easier if those resources just exist where they will be at runtime (under /WEB-INF/classes). Keep it simple – no need for 5 directories for a simple web app.

    By your statements above, you would make it seem like this type of customization is very easy. How is it done in Maven (I really don’t know – I’m hoping you’ll educate me ;)).

    Cheers,

    Les

  6. @Antony

    We’re using Maven at work, on multiple large scale projects and I can tell you that over time, Maven has become unmanageable.

    On paper its features sound great, but once you start tying in to the lifecycle and needing to do custom tasks based on the intricacies of your own project Maven just isn’t pleasant to work with. Also, we’ve found out that if we’re to upgrade to the latest version that it completely breaks our own plugins. Again, not ideal.

    I think Maven can work for some people, and that’s great, but I don’t think it’s the end-all be-all solution to project and build management.

    For JSecurity, though, I’m really glad that we didn’t go down the Maven road. And at work? Well, we’re actually having to investigate creative alternatives.

    Like any other tool and technology, YMMV, so there’s nothing wrong with choosing different toolsets, after all, every project’s different. :)

    Regards,

    Allan

  7. We’re using maven 2.

    I like the fixed directory structure, and I like the layout of that structure.

    I dislike the lack of documentation. It sucks. It sucks even worse than maven 1. After setting up Cargo, Checkstyle, and PMD, our maven2 POMs are 30-50% maven, and 50-70% dropping out to Ant tasks.

    It took about 3 weeks effort to move from ant to maven 1, and another 3 weeks from maven 1 to maven 2. Some, but no more than half, may be attributed to the bozo that did the moving.

  8. Hi Razvan,

    I’m actually really excited about Gradle. I want to use it actually. It just wasn’t perceived as stable enough at the time we made this change – 0.1 or something like that.

    But I’ve had Gradle on my radar for quite a while now and would love to incorporate it when the opportunity (read: time) presents itself!

    Best,

    Les

  9. The problem with both maven 1 and 2 is the POM itself. It is overly complicated and does not map well to the real world problems very well. It is one-size-fit-for-all solution. Most real world projects I was involved or I have seen use custom ant build sctipts to manage themselves pretty well.

    That said, I am not in favor of using custom ant scripts for projects but won’t use a techonology that will require as much work as writing custom ant scripts. Ivy seems to be more on the agile side for me in the sense that I could understand it a lot faster than maven 1 or 2.

    - Indra

  10. I use maven2 for my work (for two years) and I wouldn’t recommend it to anybody. Unpredictable, overcomplicated, with many hardcoded assumptions (often with no way to change by parametrization – this development laziness is called ‘convention over parametrization’). It was mistake – ant is much more productive choice.

  11. I use maven in my work. It’s configuration is difficult a start and there are few documentation in Maven site.

    But when I configure it (I use Archiva as internal repository ), don’t have more problems and I like it much.

    Maven 2 has a lot of plugin that are very useful, there is a great advantage in compare with Ivn.

    Maven dependencies with exclusions and profiles I think are flexible, perhaps not at all as Ivn, I don’t use Ivn.

    I think perhaps for little projects Ivn is better, but for medium to large companies with a lot of modules (Jboss, Apache, etc) maven is better.

    Sorry my english

  12. We are using Maven2 for our projects (medium-to-very-large scale). I can say that we are quite happy with our experience so far.

    Learning curve of Maven is very steep. The whole concept of build life-cycle can seem very hard to grasp in beginning. Also the concept of plugin is diff (though Ant has something similar : taskdef) along with concept of POM inheritance.

    But once well understood, you will be surprised how you ever managed with Ant before.

    Key to success of using maven for large project is divide-and-win policy and well organized POM level inheritance. In my project we build very complex artifacts using 20 line POM. That make it such a great tool.

    Another killing feature of Maven is reporting plugins. They simply great in many aspects and keeps developers on their toes to fill in the exposed gaps in their code/modules.

    Everything I mentioned above makes Maven great tool but at the same time can create a potentially dangerous pit. Best way to understand the true potential of Maven is to embrace it with open mind and be ready to change your prospective completely with regard to software building.

  13. Studies on Maven2 vs Ant+Ivy are mostly all worthless since the parties involved are next to never objective… I’m sorry, but I’ve read some arguments above against Maven which is plain wrong and based solely on the fact that, yeah, the learning curve is a bit steeper and documentation is not always crystal clear … but I fail to see why you would stick with Ant (which by the way I know really well as well) + some dependency tool (e.g. Ivy), when you can have one package that does it all + much more. I’ve seen Maven2 used in multiple very large scale projects in one single company… okay, they’ve got 2 or 3 people dedicated to Maven2 and it’s integration in Eclipse, but their environment really rocks… Junior developers come in, and in 2 or 3 minutes they can get any project in their dev environment, are able to build and deploy on their devtest server, etc…

    I’ve seen worse, believe me…spending days if not weeks setting up a development environment just because you want to fix a small bug…sound familiar to anyone? This happens fairly easily if you stick with ant (which I love, I say it again) which is simply not cut out for the enterprise world…

    just my opinion…unfortunately, many decision makers base their choice on a biased comparison between Maven2 and Ant+Ivy…

  14. @Peter

    Did you read my follow up post ;) I used both tools for a long time (I’ve even written well-referenced articles and documentation for Ant), and I have changed to Maven based on what I consider to be unbiased, objective decisions. In fact, I was very biased towards Ant+Ivy for a while, so the hurdle for me to move to Maven was higher than most. But I did it because the benefits were just too great to ignore. See my follow up post, referenced in the very first sentence of this blog post.

    Cheers,

    Les

  15. Good decision turning down Maven. Count me in the group of people who reject anything that forces the use of Maven.

    MAVEN SUCKS

  16. “Junior developers come in, and in 2 or 3 minutes they can get any project in their dev environment, are able to build and deploy on their devtest server, etc…”

    Funny, I must be a damn genious then, because apparently I’m the only one on the planet who’s figured out how to do this without Maven. Perhaps Maven is meant as a crutch for lazy idiots…

  17. lol

    to all of those hating on Maven, TRY LEARNING MAVEN … Maven uses convention over configuration, but that does not mean you cannot tweak Maven to do extremely wild things … i have through the course of my Maven experience:
    a) converted extremely complicated Ant builds to Maven (and some of these conversions required VERY creative thinking, but i still managed to get the job done in Maven, why? because I took the time to really understand the tool I was using: Maven)
    b) developed wildly complex multi-module projects with very few problems, Maven is amazing at dealing with, especially, large complex projects … again, learn how to leverage Maven so that you avoid all these pains you people keep complaining about because you never took the time to investigate the *proper* implementation of a build
    c) never had to resort to using Ant hacks inside of my Maven builds, I have successfully converted *all* wild and crazy Ant tasks that I have encountered into pure Maven, using as elegant as possible of a solution that I could have with Maven (without compromising what the original Ant task performed) … I could have given up early, like many seem to do, and just hack Ant tasks inside of a Maven POM, but u know what? i decided “no” i wasn’t going to be *lazy*, i decided to learn the tool

    the lesson to be learned here is, learn the tool, Maven is extremely powerful with its resource filtering, profiles, plugins, etc. … don’t be afraid to *learn*

    Maven adheres to a standard, which is one of the reasons why I like Maven, but this standard is just a default, you can override many things, and quite elegantly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>