Adam Bien's Weblog

Tuesday Feb 17, 2009

Maven vs. Ant

Maven vs. Ant is one of the semi-religious topics (like IntelliJ vs. Eclipse, SWT vs. Swing or Spring vs. EJB). Dependent on you specifics needs, both build tools may be interesting for you. Ant is just a framework, or a build-DSL which cannot be used out of the box. You have to create your build-script from existing Ant-tasks. The Ant tasks do not presrcibe any conventions or configuration - the definition of project layout is your responsibility. You have full control of whatever you are doing - what can become a problem in bigger projects.

Maven can be understood as "Ant With Convention Over Configuration". In fact if you rely on conventions like the "Standard Directory Layout", you can start without any fraction or configuration with maven. You will only need a good internet connection for the first build :-).

As with every Convention Over Configuration framework, you will have to understand the conventions to be able to work efficiently. In case the conventions do not work in your case, you will have to overwrite them - and the complexity of this task is really hard to estimate.

The real strength of maven is the dependency management. You only have to declare the dependencies - maven will download them, setup the classpath for you,  and even deploy the dependencies with your application if required. Maven manages not only the direct dependencies for you - but even the dependencies of the dependecies (transitive dependencies). This is the real strength of maven. Ant doesn't have such capabilities out-of-the-box (except ivy) and it will take a considerable amount of work to emulate Maven's dependency management with Ant.

I use maven and ant in my projects, the choice is dependent on the specific needs. Maven is great if:

  1. You are working with many "creative" developers. It will be hard to establish a defined project structure etc. without tool support.
  2. The developers are religious about their IDE - and are using IntelliJ, Netbeans and Eclipse at the same time.
  3. You are building a product-like application. You will have to manage different versions and branches with their dependencies.
  4. You project consists of several teams which work on dependent modules. This modules have to be composed to the application regularly.
  5. You plan to use checkstyle, pmd, generate a project website etc. Its  easy with maven.

On the other hand I would choose ant for:

  1. "Situational Software" which has to be developed quickly (few weeks / months).
  2. Projects with external dependencies which are working with "cutting edge" libraries. There is no need for finer grained dependency management.
  3. Netbeans Project :-). They come already with ant-script which even works perfectly with hudson. Just check everything into svn, and let hudson check it out...
  4. Legacy projects which do not fit the maven conventions very well. Violating maven conventions may become a hassle.
  5. Projects without explicit requirements for modularization. The deployable output will consist of only few archives.
In my case in last few years the ratio between maven and ant was about 50-50. In all indetermined cases I would tend to use ant - because of performance and predictability. Such cases, however, are very rare.


NEW: Java EE 7 Testing and Quality Workshop

A book about rethinking Java EE Patterns

Comments:

Dependency management seems to be a strength at first. Unfortunately we often have to create our own maven repository for the following reasons: Customers are usually happy if they can build their project without any dependence on third party service like external maven repositories. The dependencies of some libraries in common maven repositories are not defined really well. We often ended up very fat war files loaded with a lot of unnecessary things and from time to time incompatible versions of libraries. So when we have to fix these and maintain our maven repository (we used svn for that) we seriously were thinking maintain a few simple lib folders is a far better choice.

We are also managed to write small reusable snippets for Ant, so we can work with Ant really fast.

Posted by Laszlo Kishalmi on February 17, 2009 at 10:34 AM CET #

I am working with Maven since a year now and I won't consider ant anymore:

In case you need the flexibility of ant, you'll can always call ant tasks from Maven. However Maven saves you a lot of time.

A new project is set up within a few minutes using archetypes. I have converted a bunch of projects using ants to Maven in 2 days. These projects consisted of servlets and some web services with WS-Man. Using Ant we needed about 2 weeks to set up the projects. Maintaining the dependencies was a nightmare. Especially since the dependencies needed to be maintained twice: Once for the ant build and then for the eclipse projects. Developers that had a different IDE had to maintain dependencies for themselves.

All these problems are gone using Maven.

Even for small projects setting up a new project is way faster with Maven. However you right that Netbeans can help a lot of ant - as long as every developer is using Netbeans. But I haven't seen a project using Netbeans exclusively yet.

Posted by Carsten Schlipf on February 17, 2009 at 10:43 AM CET #

I've used Ant for some time now and tend to find it quite flexible and quick to use, as well as being fairly easy for others to pick up and understand when they come onto a project, even if they've not used Ant before. Whenever I use maven I end up with a feeling of loss of control, and a sense of uncertainty as to what's going on in my build. I imagine this is largely due to my inexperience using Maven but after my initial experience and the many negative opinions I've read, I've been somewhat scared off.

A couple of interesting alternatives I've also been looking into are Gant (http://gant.codehaus.org/) and Gradle (http://www.gradle.org/). Conceptually they map onto Ant and Maven respectively, but are both based around the Groovy language.

I've mainly been messing around with Gradle so far but have been pleasantly surprised. It is interesting to note that although Gradle supports Maven repositories it also lets you take the simpler approach of just using a local lib folder without you having to set up you own local repository.

Posted by Pete C on February 17, 2009 at 01:06 PM CET #

I've used Ant for some time now and tend to find it flexible, quick to use, and fairly easy for others to pick up when they come onto a project, even if they've not used Ant before. Whenever I've used maven I end up with a feeling of loss of control, and a sense of uncertainty as to what's going on in my build. I imagine this is largely due to my inexperience using Maven but after my initial experience and the many negative opinions I've read, I've been somewhat scared off.

A couple of interesting alternatives I've also been looking into are Gant and Gradle. Conceptually they map onto Ant and Maven respectively, but are both based around the Groovy language.

I've mainly been messing around with Gradle so far but have been pleasantly surprised. It is interesting to note that although Gradle supports Maven repositories it also lets you take the simpler approach of just using a local lib folder without you having to set up you own local repository.

Posted by 20.133.0.13 on February 17, 2009 at 01:09 PM CET #

Apologies, I forgot to put my name against the comment above (strange that it seemed to pick up the previous commenters name though!)

Posted by Pete C on February 17, 2009 at 01:16 PM CET #

> Netbeans Project :-). They come already with ant-script which even works perfectly with hudson. Just check everything into svn, and let hudson check it out...

Netbeans has the best native maven integration on earth. :-)

Posted by Christian Kalkhoff on February 17, 2009 at 01:58 PM CET #

I do not agree with arguments 1 and 5 for ant...

I don't believe that you can setup a project with Ant as fast as with Maven archetypes.

Plus: you never know how long a project lives (or how often it is reanimated), and then it is better to have a standardized project setup (IMHO).

But anyway, I agree with your introduction that this debate does have a religious character :)

Posted by Michael Pollmeier on February 17, 2009 at 02:07 PM CET #

The problem with the ant scripts Netbeans generates is that they are not manageable, there just to large. Also the classpath gets to be a complete mess if you use the Netbeans libraries for anything.

disclamer: I've been using maven for less than a month

Posted by btilford on February 17, 2009 at 03:49 PM CET #

I used to be a devout ant user. I fought the maven2 conversion tooth and nail for a long time in my company. I could just imagine the bloated projects that would be turned out by maven's transitive dependency management. Ugh! I would rather do it myself so that I know exactly which dependencies I have in my project!

Then, I was forced to make the leap to maven2. After about a week of kicking and screaming, I realized that is really wasn't all that bad.

I think a lot of it had to do with the way we set up our maven environment. We have a parent pom file for libraries that are almost always used in our projects. We have a local repository and repository manager for managing our artifacts and we use the maven public repositories for 3rd party artifacts.

I'm a netbeans user (not devout) and I can't get over how easy maven integrates in with netbeans.

Overall, my experience with maven2 has been very positive. I can still see some scenarios where you might want to use ant. But, for me, I think maven is a very solid and useful development tool.

Posted by JKilgrow on February 17, 2009 at 04:46 PM CET #

@btilford

I had similar opinion to yours. In the beginning I always used my own Ant scripts or Maven configuration. In the recent projects I used Netbeans-generated scripts - and they worked surprisingly well - even with CI. The recent projects, however, were rather small...

thanks,

adam

Posted by Adam Bien on February 17, 2009 at 09:29 PM CET #

Maven has great support for enterprises needing to manage/build products in parallel with common code across them.

This has pre-built architecture to manage all these issues with standard convensions. However for the small and medium enterprise customisation may be needed to make it more friendly to their organisation needs.

Ant with imports could give some kind of modularity but not the same level as given by default by Maven

Regards,
Raja Nagendra Kumar,
C.T.O
TejaSoft

Posted by Raja Nagendra Kumar on March 11, 2009 at 08:51 AM CET #

Well, actually it's very simple. Maven and Ant - at least as Ant/Ivy combination - are quite similar in functionality. I don't think, that you will find relevant aspects, that one of them is missing. The difference is, that Maven will do it out of the box, whereas Ant/Ivy gives you the tooling to get the same things done.

But unfortunatly, Mavens kindness is not for free (just like in real life ;-)). You will have to obey its rules. And that's the point, where the argue starts. Many people that deal with build-scripts don't want to lose control and flexibilty. Fine. Fine, if your project is really somehow special and you need flexibilty. But take a step back, look at your project and ask yourself, wether it is really special. Don't lie to yourself ... I think, quite often you will end up in recognizing, that you basically do some compile, testing and produce some artifacts.
So, there's no need to lose so much time in building something, that someone else already did, is it?

In my opinion, if you understood the Maven paradigm, you will be fast. You won't care to much about building, dependencies, packaging - it's done for you. And usually, you're not interested in this anyway - you're interested in the results, aren't you?

Don't get me wrong, I'm no Ant-hater and I'm not a religious person (at least, I try not to be). But after years of using Ant, I found out, how smooth and transparent a build-system can be.
Yet, if you have some very special stuff to - not because you just want to, but because you have to - stick to Ant!

So, I think it's all about "specialty". If you cannot get rid of specialty, you will have to use Ant. If it's just an ordinary software project, that we're talking about - and most are - give Maven a chance. And do something nice in the gained time ;-)

Posted by @rwinz on May 02, 2009 at 03:09 AM CEST #

I don't see why you would need two weeks to set projects with ant.

I just create a standard build file with some standard targets like clean, init, compile, post-compile. For a new project I create a build file and import my standard build file and set a few properties like the name of the jar file that has be be build and the dependencies its need to compile and I am done. I define my own post-compile target in the build file if I need more than just compiling some java code.
So my build files are a kind of OOP.

So ant can realy work great if you use it this way instead of the way to complex way Netbeans does.

Posted by Evert Tigchelaar on May 02, 2009 at 09:27 PM CEST #

I usually use the Maven Ant tasks for the best of both worlds:

http://ptrthomas.wordpress.com/2009/03/08/why-you-should-use-the-maven-ant-tasks-instead-of-maven-or-ivy/

Posted by Peter Thomas on May 04, 2009 at 10:30 AM CEST #

Very nice article, we'll written and finally gave me a solid understanding why I should go with Maven over Ant and vice versa. Thank you.

Posted by Frank [tOSU] on February 10, 2010 at 10:29 PM CET #

Excellent easy-to-digest differentiation. Makes it obvious why we are currently using Ant at my company, and obvious why I may want to choose Maven in future situations.

Posted by Jamie Lantzy on November 28, 2011 at 03:46 AM CET #

o0-p

Posted by 183.83.88.55 on October 06, 2012 at 05:39 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
Links
License