Maven 2 vs Ant+Ivy: Revisited

I’ve received a lot of hits and discussion concerning my previous post regarding Maven 2 vs Ant+Ivy, and I’m writing a follow up post to clarify some things.

I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.

Yep, I said it. I’m man enough to admit when I’ve made mistakes and that I’ve learned from my experiences. And this is coming from the guy that wrote a (still popular) On Java article for Ant in the enterprise.

I almost always touted Ant + Ivy as a better solution in all cases compared to Maven 2, citing:

  • Maven 2 has a steep learning curve and is a pain to come up to speed
  • You can’t customize it easily if you just need to get stuff done
  • It requires installation of a tool other than Ant
  • It just doesn’t work well for very large enterprise projects


And a few other things.

I tried Maven 2 just for kicks one or two times and ran away screaming, “I don’t have the power that Ant gives me! I can thrash out anything I wanted in Ant, but I can’t do this easily in Maven! It takes longer! Maven sucks! God I hate Maven!”

Blah, Blah, Blah. Boy was that an ignorant viewpoint. The truth was that yes, I had tried maven a few times, but I never actually used it longer than a few days and reverted to my beloved Ant. I never truly experienced what it was like over a long period of time in a real working development environment, with other developers and other projects. So I honestly couldn’t judge Maven fairly, especially in the environment where Maven really shines – multiple project teams. Let me explain:

The thing that I loved, and what many others love about Ant is its absolute control. I can do almost _anything_ I want in Ant. Same with the newer script-like build systems like Gradle. It is uber flexible, and I know that if I needed to do something down ‘n dirty, I could hash it out in Ant in a couple of minutes.

If you’re a control freak, Ant is comforting. It allows you to hack out whatever you want whenever you want. But this ability is actually the very thing that makes Ant a poor choice in a team environment. It makes it a really poor choice in an enterprise environment with multiple teams, and here’s why:

Even the most intellegent, super-smart, uber genius-geek that knows everything about Ant will still do things in a way that fits their personal mental model. Even worse, the same uber genius-geek god-of-all-developers is apt to continually insist that their way is the best way, and that they’ve worked out all the kinks, and that everyone should use their oh-so-elegant and super slick Ant build setup.

This is something I see all too often across teams and companies. This mentality actually hurts a team and has a bigger negative impact on multiple teams. The reality is is that one guy (maybe 2 if you’re lucky) is the brains behind the build system. They’re the only one who knows how do things cleanly. They know the best practices, and their environment, no matter how elegant, is often confusing to many people. Their mental model is not always the best one for everyone.

So, you end up having this one (or two) nazi-build-master(s) maintaining a bunch of ant scripts, making them more complex over time (breaking them into separate files because it makes sense to them, but harder to trace for everyone else), and getting upset if other people try to modify them. Then team members that should be allowed to modify the build to meet a new need can’t or are afraid to.

In any event, the overall team productivity related to builds and continuous integration often slows to a trickle. This trickle causes frustration, alienates people and discourages their interest and help, and costs the company money. It is clearly a bad, bad thing.

Maven remedies this all too common situation and many others. Once a few developers use the Maven XML structure and understand what those tags do, they can jump from project to project, as business requirements deem necessary and immediately understand another project’s build environment. That means they can build the software and start testing it right away. This efficiency translates into enhanced developer and team productivity and that means real money saved for the company.

And guess what? Newer developers hired in to the company that have Maven experience can also jump right in on a project and understand its build environment for the most part. That is a big benefit. At my workplace it used to take a new hire almost a week to feel comfortable understanding and building a very large project. After converting to Maven, new hires are literally up and running in under an hour.

But this efficiency is not just valuable for the company. It is valuable for developers’ sanity. I am comforted now by knowing that I can jump from projects at work to a few hosted Apache projects to some other 3rd party projects and, if they use Maven, I am right at home and understand exactly what is going on. I know immediately how to

  • download dependency source code
  • run tests
  • generate JavaDoc and other documentation
  • Start up a test web environment if it is a web product
  • view a continuous integration environment
  • see source control repository details
  • understand how the project is broken up into modules


and so much more. That I no longer have to think about these things, things that were very very time consuming when having to manage yourself, even with Ant, is a big load off of my mind. I just don’t want to mess with this stuff anymore. I want to have it all work, not waste my time, and allow me to have my piece of mind so I can go crazy worrying about other things like deadlines. That I can get this piece of mind from project to project and team to team when Maven is employed is a real benefit.

And to my previous comments about Maven not working well in very large enterprise projects because of the possibility for a lot of ‘one off’ custom logic? That didn’t hold. I’m working with a very large codebase at work that sometimes takes over 30 minutes to build, not including integration tests, and Maven fits the bill beautifully. Sure, there are those few ‘custom’ things that we needed done, but we learned to write a Maven plugin or two (as you should) and use them extensively. Sure, I couldn’t thrash out an Ant hack to get what I needed done, but so what – the team understands what these custom plugins do, they are self documenting, and easily maintained and managed in source control by other developers because Maven plugins themselves are fairly conventional and easy to understand once you learn about them. This goes back to continued efficiency…

Don’t get me wrong – there are some gripes I have with Maven, but they’re not really a big deal compared to all the benefits we receive. It is not a silver bullet – nothing is – so you take those few frustrations and set them aside, knowing the alternatives are much more painful. So maybe I’ll call it a bronze bullet? ;)

And so, as JSecurity has moved to Apache and has been renamed to Apache Shiro, we too have moved to Maven 2. We have also moved to Maven 2 at work as well, and we now benefit from some other amazing tools like Nexus that integrate well in a Maven ecosystem.

Overall, life with Maven is good. I’m glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven’t used Ant in over a year since switching, nor have I ever felt the need to go back.

24 thoughts on “Maven 2 vs Ant+Ivy: Revisited”

  1. Very good points, I’ll admit to being a “nazi-build-master” myself in the past ;) as well as experienced first-hand the horrors of joining a new project with a monster Ant build created by the resident ‘nazi’. Ant calling a bunch of Groovy scripts in that particular case, yuck – not pretty.

    I’m not yet 100% on the Maven bandwagon however. Granted, it is the future – and I also agree that Ivy is not the answer. I advocate an approach that uses the Maven-way as far as possible and falls back to Ant for those ‘custom stuff’ cases, which for some reason, I run into a lot.

    IMHO you dismiss too lightly the challenges when it comes to writing custom Maven plug-ins, for example you have to ensure that they are in whatever repository your enterprise developers use, that everyone is pointed to it, what happens when people work from home etc. I work on a couple of open-source projects and it is much easier to roll-out complex build tasks via an Ant build instead of via Maven.

    One thing I really like about Ant is the IDE integration, and for e.g. running a custom target from a NetBeans (or Eclipse) shortcut is much faster than using the corresponding Maven way, even using the -o / offline switch doesn’t reduce the time by much for some things – that’s just how Maven is.

    I blogged some of my thoughts here: Why you should use the Maven Ant Tasks instead of Maven or Ivy, note that structuring your project the “Maven way” is the way to go, and if you ensure the “core” / standard parts of your build execute correctly through Maven – it means that your build passes the “enterprise” test.

    Hmm, by the way since Maven 3 is going to natively support scripting (using Groovy etc) does it mean that we will run into Maven “build-nazi”-s in the future :P

  2. Yes, nice article. I agree with you with a lot of what you said. ant is fantastic but does not suit when you have lots of projects. Maven gives a structure and helps a lots in that point. You really hit the point, we all need a tool like maven. But I still have a lot of problems with maven : too much magic, most of the time you have to add plgins and plugins… If you change something in the config, you often have to delete a directory in the repo or in the plugin directory – last time it was with hudson or the sonar plugin… You don’t guess anything. Beside the first steps of the build, you have to configure everything. When you begin to have problems, you need a maven guru near you. Etc. Maven is great… when it works. It is not as easy to learn and use and configure as it should be.

  3. Show the Ant nazi-build-master a .jar file from one of his continuous integration builds that was created 2 years ago and then ask him to produce a bit for bit identical version of it from source control.

    “No problem”, he’ll say.

    Then show someone from the group with the Maven builds that anyone can work on a .jar file from one of their continuous integration builds that was created 2 years ago and then ask him to produce a bit for bit identical version of it from source control.

    Deer in the headlights.

    To some people that doesn’t matter, but to me it does. I have in the past worked with a group that used Maven and after learning of the way that they had it set up, I pointed out to one of them that they couldn’t reliably reproduce builds. He didn’t seem to think it was important.

    Why not make it really easy for the developers and let them take whatever they build in the IDE and just ship that?

  4. @MJ

    My experience has been the exact opposite. Almost to the extreme – that Maven projects have a much better chance at recreation than any Ant project I’ve seen. Maybe the group to which you refer was just extremely naive about how to set-up and use Maven. Any build tool can be used poorly. There is no excuse for ignoring the large amount of documentation for any build tool and then doing your own thing blindly.

    But to the recreation point, Maven is actually slightly better suited for recreating a bit-for-bit version of the software when all you have is the binary artifact:

    If the project uses common version conventions and use standard Maven conventions, the binaries will have the version numbers in them: something-1.0.1.jar, somethingElse-2.1.5.jar, etc.

    If the project has any sense at all, they would have created a version control tag to mirror that concrete version number. Once you have that, you can easily do a checkout of the code and get a bit-for-bit recreation of the artifact.

    Contrast this with Ant – unless the ant build artifacts use this same versioning convention (and the large majority of Ant builds do not do this, as most Ant build files don’t retain application version numbers), you’re far worse off – you wouldn’t know how to find that version control revision number at all.

    The other way to do this is that the build puts this version number in the Jar’s MANIFEST.MF file. This is a much better thing to do, because not only can you include an application version number (2.8.2), but you can include the RCS revision number as well (e.g. SVN r.323092).

    Maven makes this other approach MUCH easier than any Ant build I’ve ever seen.

    I hope that dev team learns to use the tool rather than blindly just copying and pasting Maven files they found elsewhere ;)

    Best,

    Les

  5. Les,

    Thank you for your informative and honest post. There is just so much ignorance and disinformation about Maven out there and it’s nice to see an article by someone who has actually used Maven properly and knows what they are talking about. The link posted by Sam was obviously written by a guy who doesn’t. MJ’s post also reveals how little he/she knows about how to use Maven and SCM properly. It’s a shame, but it’s incredibly common. I had to really sell Maven to the guys on my team because of what they’d heard about Maven. They still complain occasionally, but it’s almost always related to IDE integration issues and not core Maven functionality.

  6. In your previous post you made quite strong (and valid in my opinion) statements about Maven deficiencies. Most important of them are not flexible enough dependency management as compared to Ivy and “black magic quirks” related to build process and its customization.

    Now you claim Maven is better then Ant+Ivy, though you do not reveal your current opinion on mentioned issues. Did you find the way to solve them? Did they become not important for you anymore?

    Without touching this your post looks more like a rant.

  7. Tony,

    You are referring to ignorance and disinformation about Maven and people blaming it without understanding. Come on, the post that Sam pointed us to contains plain facts about issues with Maven. A lot of facts. Would it not be better to disprove them if they are completely wrong? This way you will effectively eliminate this “ignorance and disinformation”.

    Simply claiming “my tool is better, you just don’t understand it” is so childish and brings nothing valuable.

  8. sure, maven is not perfect, at all, but it’s not bad either. too bad 2009 was the year where it was fashionable to say ‘i hate maven’, resulting in people who know nothing about maven, saying maven is bad. but also, times changes … maven was great 2-3 years ago, starting from the Maven 2 version. but at the moment Gradle (you get the best of Maven, ANT/GANT and ivy) is the only true contender for Maven, but it still has a long way to go.

  9. I think the most important topic which is missing in this discussion and similar is type of development process in a project. If it’s corporation (as it seems it’s the case in this post) then maven is good. There are many developers changing the same code, team is big, there is people rotation between projects/companys. Code quality is low, there are no “owners” of code/development process, work is driven by business processes. In this case tool which enforces specific usage gives better value than tool that is flexible.

    But in “agile” teams (small, small rotation, people are owners of code and development processes) flexibility and possibility to customize build tool to specific team’s needs gives an order of magnitude greater value. In such small and self-supporting teams there cannot be “nazis”.

    So the motto is: leave corporate, drop maven, and use ant in a smaller company ;).

  10. I get your point about the benefits of the maven conventions on team development. I even have thought the exact things too. However as much I appreciate maven, I cannot let Ant out of my heart as the favorite build tool! That is because I am a control-freak, and yes, it allows my build to the level of perfection that I want.

    I use maven because I have to, but Ant because I want to.

  11. So what if your dev environment does not have an Internet connection? (Or heck, what if it’s just down or slow one day?) What if you don’t WANT Maven downloading new versions of who knows what without you knowing it beforehand? Or what if one of these “automatically integrated” dependencies breaks your build due to some conflict? The problem with “magic” is that when it breaks, you’re SOL.

    Ant can do most everything listed above as Maven benefits, if you really need it to (some “benefits” are just distractions and are of trivial importance in the grand scheme of things..). If you have someone over-engineering your Ant build files making them hard to comprehend, don’t blame the tool, blame the idiot.

    Bad move switching to Maven. Your original decision to use Ant was correct. Most people dropping Maven are ditching it after using it for a long time (not two days), once they’ve run into a few of those “gotchas” that makes them waste hours or days resolving it. But it takes time to encounter these.

    I almost never have to touch our Ant scripts. Much better spending your time working on the actual product instead of blowing hours (or days) on a tool used to build the product. Read some of the Maven horror stories out there. No such stories with Ant. And they aren’t from “Maven newbies”, either! I see no reason to use “Maven”–or any project/example that requires it.

  12. Nice article, Les. You have accurately summed up what a lot of large (and not-so-large) organizations find so appealing about Maven, despite the circulating FUD. And, for the record, your arguments still also apply for agile teams – even agile projects need to be maintained eventually!

    Regarding the myth of the automatically updating dependencies quoted in the previous comment, I documented and disproved this rumoured behaviour here.

    Thanks again for a great post!

  13. This was interesting reading, as you could have been writing about the exact process of discovery I’m going through now.

    I’m in a corporate environment on a team with multiple java developers, any of whom might in fact need to work on any and all projects at some time or another.

    How do you minimize the amount of man-hours needed to maintain project structure, dependencies, and build methodology, and (in our case) do so without a dedicated configuration/build manager? Really it comes down to: How do you maximize the amount of time your development team has for developing the end product?

    The answer is to minimize the amount of time it takes to achieve ancillary function X (efficiency), AND ensure that function X is always achieved the same way from project to project (eliminate duplication of effort, and reduce learning curve by maintaining consistency).

    Maven seems to fit that bill nearly perfectly.

    Still, not wanting to commit without due-diligence I decided to poke around and see what others have to say. There seems to be a LOT of criticism around Maven’s rigidity. Frankly, a lot of it is pure ignorance (Maven’s relatively poor documentation promotes this, unfortunately), but some of it is clearly based on some valid points, and backed up with some detailed experiences.

    Truth be told, that has me somewhat concerned. But it flies in the face of what I’ve already experienced, and there exist a number of other articles such as this one which detail the exact opposite experience.

    What it _seems_ to boil down to to me is that developers who are not on a team, and tend to be either the masters of their own projects, and possibly even the only developers, seem to argue against Maven, while people who work on teams (particularly with highly “creative” developers), tend to sing the praises of Maven.

    In the end, my concerns are outweighed by three facts: (1) experience with Maven so far has been great (for all the reasons mentioned and more); (2) the initial effort required to implement it is nearly zero; (3) the effort required to stop using Maven if it proves to be a problem is effectively zero — just stop using it! We can still go back to Ant if we want to.

    I should point out that we are not migrating to Maven from some other established mechanism… right now there is no mechanism (don’t ask). So there is less potential loss than if we were abandoning some existing system.

    Also I have an eye on Gradle — it’s too young for me to feel comfortable with it (and lacks some features), but if Maven turns out to be too rigid then Gradle seems to provide the benefits of Maven without the rigidity.

  14. I think both Ant and Maven are equally painful. I never quite understood why building projects for any Java project is so difficult when I am able to consistently get a Visual Studio solution to build with virtually no effort, time after time, years after I initially created them using the .NET framework.

  15. See, I think it’s the other way around. Maven is going to be overkill for any small or mid sized project working in a single office. The large ones are where it has a -better- defense. We have a number of projects (not huge, but big enough) that are built with Ant and the build isn’t that complicated. Maybe 2-4 screens worth of ant script– how is that a big deal?

    I’m sure they’re all over the place, but complaining about Ant builds that are impossible to understand sounds an awful lot like complaining about a project or source code that is impossible to understand. Ant is like a programming language, if you use it stupidly, it’ll get confusing. I suppose if you aren’t familiar with how to create an intuitive build process, Maven is more idiot proof… but so are “application builder tools” and their likes. (MS Access, Oracle APEX)

    I just can’t see the use in these things (or the problem with doing them in Ant) for a project/team that isn’t huge.

    -download dependency source code
    (just drop the source jars into svn? also, no worky if you don’t have an internet conn. and… over-use of dependencies is a valid concern.. not something to be encouraged, look at the mess Spring, Spring Security, and other bloated OSS projects have to deal with now. dependencies may help speed things up a little in the short term–but for the ‘users’ of a lib and over the long term, they’re nothing but a bad thing to cause problems)
    -run tests
    (ant does it fine, if you even need it to, and honestly unless you’re doing a release or commit, mandating the execution of tests every single build can waste time. just test when you need to, testing and building aren’t always done together)
    -generate JavaDoc and other documentation
    (ant can do it fine. and is it really impossible to “just look” at an ant view in Eclipse and immediately understand how to generate docs by clicking on the task? it couldn’t be easier)
    -Start up a test web environment if it is a web product
    (install, build/deploy, start? what’s so complicated?)
    -view a continuous integration environment
    (small teams don’t have the resources to set up, create tests for, and maintain a cont int env, and unless your code base is massive it should be well enough designed that this isn’t a serious need anyway)
    -see source control repository details
    (other tools do this just fine, not sure what the point is?)
    -understand how the project is broken up into modules
    (isn’t there documentation or architecture diagrams? and if you’re being tossed into a project with no introduction or assistance, just a ‘here’s your task, good luck figuring it all out for yourself!’ it’s going to suck regardless)

    And Maven IS slow. Aren’t compilers and software slow enough as it is without adding extra magic to make the problem worse?

  16. Actually here’s a simple way to describe the problem with Maven: Maven aims for perfection–a development utopia. It tries to be The Tool To Rule Them All, which can even toast your bread and make you coffee. Well, we all know that’s not realistic. It’ll never happen. Only for the lucky few where it just happens to jive with your requirements and users will it perform well; when you expand that to fit the multitude of different types of development environments, it falls apart. We also know that trying too hard to find perfection can backfire and lead to worse situations than what we had to start with (thanks for that, Karl Marx)…

  17. For Maven builds to be reproductible, you must “pin” the version of each and every plugin used (even the “default” ones, like the Java compiler, etc.).

    To make matters worse, several plugins have bugs which are only “fixed” in (SVN, CVS, etc) but not released.

  18. Takes 30min to build? Even mid-range projects: 200.000-400.000 loc shouldn’t take THAT long.

    Still, I understand your points. But I think all kind of customization for a specific build (custom build plugins) that have to be adjusted and modified during the lifecycle of a project shuold be done with some kind of script language like groovy and checked into the project repository.

    Once that build customization works fine, it can be compiled into a real maven plugin with java and stored in the company maven plugin repo.

    Just my 2 cents

  19. As far as I’m concerened, this debate is over. Maven is better than ant, PERIOD! Now Gradle can compete with maven and eventually overtake maven. However, maven is simply better than ant for any attempt at continous integration. It all comes down to this: any web-application that would be deployed in a standard container is NOT special in terms of its strucutre. So, what is the point of wasting your time (and everybody’s time)? You would end up conforming to the standard of the application container that you want to leverage. That said, learn ant and truly understand it for historic purposes.

  20. I’m a young developer with 5+ years of experience. I can honestly say that I’ve used Maven from the very beginning – at least 95% of my professional life – and I’ve been really happy with it. I can’t say I know anything about the pre-Maven days and understand every problem there could be with build environments, but I know a lot about Maven and have been using and designing builds for many products with it. I’ve also used Ant-builds and Ant+Ivy-builds.

    The thing that strikes me the most is the actual feeling I get from entering a project that uses Ant or Ant+Ivy. The feeling is usually complete horror and frustration. Every project has the same basic configuration for the trivial stuff (compiling sources, test sources) etc. copy-pasted from other projects. But even the trivial configurations and dependencies are always just a liiittle different from the last time (usually long and tangled, almost always ordered differently and depending on random properties-files and whatnot) so I have to use some thought to completely understand even the most basic aspects of the build. Only after that I can get to the advanced stuff.

    I have almost never had this problem with Maven because it has more strict structures for the trivial stuff and discourages use of custom ant tasks (I still use them sometimes) and properties files. I am biased of course because I’ve used Ant much less, but I understand where it’s coming from and I’ve never felt I need that much flexibility. Throwing Ivy in the Ant-mix just seems to add more complexity and configuration files to the build. All in all, usually me entering a project that has an Ant or Ant+Ivy build results in me converting the team(s) and the project to use Maven and most of the time the only problem that arises is the psychological trauma I get from conversations with senior coders with arrogant Ant-biased attitudes :)

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>