February 20, 2010

Maven vs. Ant: Stop the Battle

Maven? Ant?

Oh boy, how this bothers me. The endless debate and religious battle about which build tool is the better build tool, no, is the one and only right build tool...

There are many people out there who love Ant, who defend Ant with their blood and honour. That's fine, but some of them at the same time shoot at Maven. There is so much rant about Maven, so much unfair allegation and just plain wrong claims. This is just one example that has been discussed in the community lately.

Don't get me wrong. Maven has its flaws and issues, sure, and you don't have to like it. Use Ant, or Gradle, or Buildr, or Schmant, or batch files, or anything else if you like that more. But, Maven definitely can be used to build complex software projects, and lots of people are doing exactly that; and guess what -- some of them even like this tool... So, can everybody just please use what he or she likes the most for building their software, and stop throwing mud at each other? Let's get back to work. Let's put our effort in building good software.

We've Come a Long Way...

You may have guessed, I think Maven is the best build tool, at least for the type of projects I am dealing with in my company. We have started using a complex system of mutual calling batch files long time ago, and switched to Ant in 2000. That was a huge step ahead, but still it was a complex system with lots of Ant-Scripts on different levels. So we moved to Maven 1.0.2 in 2004 for another project. That brought nice configuration and reporting features, but still did not feel right, especially for multi-module projects that were not supported in the Maven core at that time.

When Maven 2 came out, we adopted that early and suffered from many teething troubles, but nevertheless we were sure to be on the right track. Today, Maven is a mature, stable, convenient build tool for all our projects, and the first time we are quite happy with how it works and what it provides. Moreover, it sound really great what the brave guys from Sonatype have in their pipeline: Maven 3, Tycho, and all those nice tools like Nexus and m2eclipse...

Hence, I am happy and honestly don't really care very much about what the blogosphere is telling about Maven. But the sad thing is, my colleagues (mostly used to Ant build systems) are complaining with the same weird theses about Maven. I'll give you one example.

The Inhouse Battle

In my current project, we create EJBs in some JARs and assemble an EAR file for the whole application. Now we have to create another RAR to be put in the EAR, so I setup a new project (following Maven's convention "one project, one artifact") for the RAR. This is what the "Ant guys" didn't like: "Why can't Maven create that RAR within the main project, you know Ant could do that, so maybe we should use Ant here again, why have so many small projects, this is polluting our Eclipse's Project View, so much complexity, Maven sucks, I knew that before, blah blah..."

Well, I tried to explain that Maven of course can be configured to create multiple artifacts per project, but that's not the recommended way because it violates Maven convention. It's all about modularity and standardization. That is how Maven works, and it's great this way. A small project is not much overhead at all, it is going to have a clean and simple POM, and by the way we discovered a dependency cycle in the code that had to be fixed in order to move the RAR code into a separate module.

So, what's wrong with Maven? Is it just that you want to do it your way and not to subordinate the Maven way? A matter of honor and ego? Is that enough to kick out Maven and go back to your Ant and script based build system (which BTW is so complex that only few guys really know how it works)? Come on.

The Bottom Line

IMHO, standardization of build systems is one of the main benefits that Maven brought to the world. If you know one Maven project, you can switch to any other project built with Maven and feel comfortable immediately. This increases productivity, both personally and for your company, which is one of the reasons more and more companies switch over from Ant to Maven.
We have clean conventions, a nice project structure, and a highly modular system. And, we have world class reporting with minimal effort.

You see, that's why we are using Maven. If you don't like it, go your own way but let us just do our job.


  1. I really couldn't agree more.

    My current project started three years ago, and we chose to go with maven at that time. It was new for all of us, and I got to be the one setting up the build.

    It was frustrating in the beginning, at times because of bugs in maven plugins (surefire + testng integration was flaky at best at times), but most of the times just because I wasn't familiar with the "maven way".

    Now I'm really glad we persisted with maven, since we ended up with a project that produces 6 wars and consists of about 20 modules.

    The natural modularity a maven build can give you really helps with those complex projects: I think we would have ended up with fewer, much larger and less specialised modules if we would have had an ant-based build, because adding an extra module would have taken more effort than with maven.

    An added advantage is that almost everyone actually understands the build and can adjust it where necessary.

  2. the negative rants with false claims, that's what bothers me too. and for the same reason as you mention. these rants tend to influence people who know almost nothing about maven, to decide that maven is not good enough. i'm having the same problem at work too. our team made the decision to go with gradle instead of maven. but this decision wasn't based on objective arguments. in fact, most had little or no experience with maven. i've even written a small post about this on my blog. i use maven on a regular basis since 4 years now, so i knew what it could do for us and i knew it would work very well. but i couldn't convince them for the following reasons: verbose XML, only works for very basic standard projects, maven is passé (is that even an argument?). so we're now using gradle (still 0.5 although there's already 0.8, but they don't want to upgrade yet because of the somewhat instable api of gradle at the moment). it's not that bad of course, but ... almost no support in IDE for dependencies, not a lot of plug-ins yet, still long build files, no sharing of dependency configuration between projects, tedious release process, very basic and tedious repository management with Ivy, build breaks a lot because someone changes some stuff in the gradle plug-ins we crafted ourselves. at this point it's costing a lot of money.
    the point is that they've made a decision based on what others are saying and not based on their own experience.
    my main argument was that maven has grown over the years and that gradle will need to grow first to effetcively be better than maven (i think gradle is conceptually better than maven).
    as an example of the stuff we are facing now: we use an Ivy descriptor in combination with Ivy plugin for eclipse, but that doesnt' work well with EAR projects (it does work for WAR projects) in RAD. so i had to write a small script to generate the JAR's in the project and then manually configure the build path in eclipse (and this needs to be done with every change in the dependencies). another example is that for 75% of the dependencies the sources jars/zips are not in our ivy repo (i guess they are not adding them to the repo to not loose to much time setting up a repo). and i hate to develop without having the sources of the 3th party jars i'm depending on.

  3. @sdb Wow, this gradle stuff sounds quite similar to our experience with Maven around end of 2006. As you said, Maven definitely has grown since then in terms of usability, stability, maturity. Let's see how long gradle will need to catch up.

    This mentioned argument against Maven ("it only works for small projects") is my favorite one. "Our own project is quite big, you know, it just can't work." Boy, how crazy. And after showing them a couple of really big open source projects, know what the reaction was? "Sure, it may work for big open source projects, but we have closed source stuff and that's a different story... it just won't work..."

    Well, what should I say, we tried and it just works :-)

  4. Whatever the build tool, the important things to standardize on are the repository structure and a repository manager. While you can use the Maven Ant tasks, I often wonder about people that would take all the effort to recreate that in Ant.

    @Christoph, I've also seen people use both sides of the argument. "Well our stuff isn't complex enough to require Maven.", as well as, "Our systems are too complex to rely on prepackaged build systems."

    While there's too much "religion" in the argument. (Maybe I've made it worse?)

  5. "Maven definitely can be used to build complex software projects" – exactly, but you have lost one important thing – “…complex software projects with dependency management requirements”. It appears to me it is not correct to compare Maven with Ant, since Ant does not provide facilities for dependency management at all.

    “… standardization of build systems is one of the main benefits that Maven brought to the world” – if you need standardization it does not mean that you need Maven. You can standardize build process with Ant also. For this purpose you can create skeleton for build file with PREDEFINED tags such as compile, jar, test and so on and use Ant task “import”.

    I think Maven team is actual reason for these wars - Maven against Ant. Why they did not use existing Ant infrastructure, but instead created build system from scratch? Ant did not provide dependency management that time, other features were already supported, what they just needed – append dependency management into existing Ant environment and we would live in peaceful world.

  6. @Vic: "complex software projects with dependency management requirements" -- can you imagine complex (even not-so-complex) software projects that do not require management of their dependencies? Of course, committing libraries to SCM is also kind of management, and we did that for years, but I don't want to do that again.

    "You can standardize build process with Ant also" -- right, then you have your private (inhouse) standard vs. the "industry standard" provided by Maven. With Maven, projects are easily comprehensible across departments, companies, countries. If a new (Maven aware) member joins the team, he needs 30 min to completely understand our builds, and we never had this experience before.

    "Why they did not use existing Ant infrastructure, but instead created build system from scratch" -- I think it's more than adding dependency management. It's also declarative approach, standardization, modularization, conventions, reporting and more.

    I agree, though, Sonatype is sometimes somewhat harsh with competing software. That may, in turn, be caused by the unfair bashing Maven is exposed to.

    In the end, we all just want to make our job. If Ant fits to some task: fine, just use it -- I do so myself for some rather simple tasks that do not require the full build lifecycle. If others use Maven for their projects, we should let them do so without telling them all the time that Maven is crap. If someone thinks gradle is the best build tool ever, go ahead and be happy. Let's just stop the battle ;-)

    It's this "religion" that really annoys me. I don't see that in other areas -- for instance, when using logging frameworks, you have a couple of choices as well (log4j, commons logging, slf4j, ...) with all having pros and cons, but people don't fight with each other about which logging framework to use.

  7. Ant ? Maven ? Why bother with old solutions ? Why don't we move forward to Gradle ?

  8. I succeeded in building a large-scale complex web application using Maven2 and it has given us pains along the way, but I never regretted the decision to move away from using ANT. Since then I am consulting on a project that uses ANT and it works fine until there are improvements or problems requiring changes to the build script. With Maven I search Google for the answers and with ANT I must read through thousands of lines of a build script to figure out how the build is working for this implementation of ANT builds.

    ANT and Maven are two different animals. I imagine back in the day people argued about programming languages C vs. Assembly. Abstraction is always the natural progression and I really don't need to know how something works as long as it is working...this way I can spend my time building better software applications.

    ANT will remain to be used for those custom situations that are not standard across applications, but for the standard situations why should I have to learn the details of how this development team decided to implement the packaging task (for instance) compared to the way I implemented the packaging task several years ago when I built in ANT. I'd rather be looking at the project build descriptors and recognize the common tasks immediately without sifting through the details.

  9. Man, don't let me wrong, but I think that this talk about maven is a completely bu!!sh!t.
    To build, think: Ant!
    it's the simple and evolutionary solution...
    Be a guy, be an ant, but be gay, choose: Ant.

  10. Both have their good and bad points. ANT is flexible but because of that allow bad non modular scripts to be written.

    Maven imposes a rigid structure, but with that loses in flexability, and is really only an option on new projects. I wouldn't like to refactor a large existing build to fit Maven.

    As for committing dependency libs to the SCM, what do you do if your product outlives your external dependancies? Sorry Mr manager I can't build the software because I never baselined our dependencies, doh.

  11. I was wondering if after more than a year, with Maven 3 out, there is still a trade-off between which one to use?

    Let me put it this way, Consider a newbie trying to figure out what is the easiest way to automate build process ? Do you recommend Ant+Ivy or Maven ?

  12. @config-man: When using Maven for more than just sandbox projects, you of course also will install a Maven Repository Manager, right? Use that to permanently deploy all dependencies that are not any more (or have never been) available on the Internet. This is the Maven way, and there is still no need to commit those artifacts to SCM.

    @Shahin, for me things are quite clear: if you are dealing with complex projects and/or larger teams, go Maven and forget about Ant. You will greatly benefit from higher standardization and all functionality that is built into the wealth of plugins. Maven 3 is faster and more stable than ever, and integration into Eclipse got much better with Eclipse Indigo (3.7).

    Hence, from my point of view Maven definitely is the easiest way to automate builds -- at least for new projects. Adopting existing projects (based on Ant or something else) might be very challenging and some bunch of work, but could still be worth the effort.

  13. I have to admit that I have prejudice against maven. This is because I used to use ant and I like it compared with another tool which was written in Perl. But prejudice aside, what's annoying me is that a project keeps changing its build system. Now we have a working ant, and some guy came up and change it to Maven. Once I got a bit familiar with Maven 2.0, now it's moving to 3.0.

    Does that improve the project's quality or productivity. I think not. If you be realistic, you can find Maven does not do much differently from Ant. And the benefit the Maven would bring to use may be well counter balanced by its defect.

    What maven can do also can be done with Ant. If you start a new project you can pick up Maven that's fine. But using it to replace a already working ant doesn't make much sense.

  14. we have a rather complex system structure, with 100+ modules, parent-child structures of build dependencies, code analyzers and so on...

    all our systems are based on ant (building and task automation) + apache ivy (yep. dependency management with ant) + nexus (apache ivy is compatible with maven repositories. FTW)

    we tested mature releases of maven and ant +friends before we went with ant.

    MAVEN PROS: maven is stable, mature, supports complex build structures with module inheritance, helps you managing dependencies, [put your favorite here], etc.
    MAVEN CONS: ant does the same if used correctly.

    the only drawback i can notice choosing ant instead is that people tend to believe maven is the only way of doing things and there is no complete / easiest / technically affordable choice. maven is a fine tool.

    albeit i don't like maven ways, i am not telling you "go with ant". instead test both and choose the one you see it fits based on your own experience.


  15. I just have a simple que. that when a novice ask you for primary level which is the best to go..?? what is your answer for that.??

  16. I prefer Maven because it enforces a uniform project structure and modularity. The same can be done with Ant, but in most cases Ant-based projects end up with 2000 lines long Ant scripts and messy project structure. Now I am splitting a huge ant - based project into Maven modules, and it enjoy every minute of the process.

    It is better to have a tool which forces an average developer to manage dependencies and think about modules than relying on a world-class engineer to implement modularity with Ant because an average developer will never care about modularity with Ant. I think that enforcing a good engineering practice pays off.

  17. We were a small team using ant build scripts that were auto-generated by Netbeans for a fairly complex project that built a .war from 7 separate projects. People tell me that this setup is not scalable, but it worked and required very little maintenance. It was easy to set up, it rarely required us to go under the ant covers, and we had few problems updating code and build scripts across several geographical regions. Then we switched to maven. Now builds break more often and only 1 person really knows how to fix them. The old ant builds allowed quick rebuilds on a single project, where with maven I seem to have to do alot more full build operations -- this adds 20-30 minutes of build time over a typical 8 hour day. I am told maven is better because of dependency management and all, but we were doing ok with our libraries in subversion. I feel that I am less productive as a developer now that we have maven, and I get more build problems that I can't figure out how to fix. If you have the luxury of a dedicated build engineer to optimize and maintain your project then go ahead and use maven. If you're a small team that needs to be dedicated to writing code instead of build scripts then I'm not sure that's the best choice.

    1. I had the same experience, but using Eclipse instead of Netbeans. Ant "complex" scripts are not a problem, since they are automatically generated from Eclipse projects, and connect nicely with the Jenkins server.

      I also feel that Maven asks for "too much attention", building the system should be transparent, not something we have to take care of.

  18. Great blog,much needed,thanks for sharing.
    IT Services

  19. Thanks for Sharing This Article.It is very so much valuable content. I hope these Commenting lists will help to my website
    devops online training
    best devops online training
    top devops online training