Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Maven or Ant?

02.17.2009
| 70443 views |
  • submit to reddit

Maven vs. Ant is one of the semi-religious topics (like IntelliJ vs. Eclipse, SWT vs. Swing or Spring vs. EJB). Depending on your specific needs, both build tools may be interesting. 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, which 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 friction 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 its dependency management. You only have to declare the dependencies and 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 via 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. These modules have to be composed to the application regularly.
  5. You plan to use checkstyle, pmd, generate a project website etc. It's easy with Maven.

On the other hand, I would choose Ant for:

  1. "Situational Software" which has to be developed quickly (in a 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 projects :-). They come with predefined Ant scripts which even work 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 a few archives.

In my case, in the last few years the ratio between Maven and Ant was about 50-50. In all indeterminate cases, I would tend to use Ant because of performance and predictability. Such cases, however, are very rare.

 From http://www.adam-bien.com/roller/abien/entry/maven_vs_ant

Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Grzegorz Borkowski replied on Tue, 2009/02/24 - 4:52pm

I've read many hot discussions "Ant or Maven". However, one of the most important Maven assets is always missing in this discussions. The significant advantage of Maven is that it provides you with kind of API for getting to know about project metadata: its structure and build process details. This means that you can write the tool that will take project pom file, merge it with Maven super-pom, and it will know all about this project: what are source directories, what are test directories, what is target directory, what are project modules, dependencies between those modules, etc. This makes possible to write fully-operational Maven plugins for different IDEs. With such plugin, you simply open the pure-Maven project (vide NetBeans) or import it (vide Eclipse) without having any IDE-specific files. For me this is crucial, as I switch often between those two IDEs, and I don't like forcing anybody from my team to use one IDE or another: I believe if the developer is most productive in IDE 'X', he should be allowed to use X, not forced to use Y.

This is impossible to accomplish with Ant, because Ant doesn't provide any project metadata. It simply a script with some tasks and targets. But no metadata. I remember when I tried to use the Netbeans support for "free-form projects" (ie. based on not-IDE-generated Ant script). It worked, but still required much work. Now, when I use Maven, i simply open any maven project in Netbeans, with one click, and it's ready to be build. 

Additional benefit is that now I don't have to version-control IDE specific files, which was often required in ant-built projects. Now, when I use Maven, it is no longer necessary: all information is in POM.

Final remark: I don't say Maven is perfect. It has many many flaws, bugs and problems, and poor documentation, and often I really hate it. But I haven't found anything better yet. And I cannot imagine starting any new project using Ant instead of Maven. Writing those scripts again and again and again again... Oh no! This is like coming back from capitalism to communism - capitalsm is far from perfect, but you really don't want to go back to communism (ask anybody from Easter Europa :). 

 

Edwin Quita replied on Tue, 2009/02/24 - 5:36pm

Organizations and projects that adopt Maven benefit from: • Coherence - Maven allows organizations to standardize on a set of best practices. Because Maven projects adhere to a standard model they are less opaque. The definition of this term from the American Heritage dictionary captures the meaning perfectly: “Marked by an orderly, logical, and aesthetically consistent relation of parts.“ • Reusability - Maven is built upon a foundation of reuse. When you adopt Maven you are effectively reusing the best practices of an entire industry. • Agility - Maven lowers the barrier to reuse not only of build logic but of components. When using Maven it is easier to create a component and integrate it into a multi-project build. It is easier for developers to jump between different projects without a steep learning curve that accompanies a custom, home-grown build system. • Maintainability - Organizations that adopt Maven can stop building the build, and start focusing on the application. Maven projects are more maintainable because they have fewer surprises and follow a common model.

Oleksandr Alesinskyy replied on Wed, 2009/02/25 - 7:41am in response to: Edwin Quita

>Maven allows organizations to standardize on a set of best practices. Would agree - if you remove word "best" as it is very questionable in this context. I as well may sustitute it with "worst" - neither of both is proved. Statement concerning "fewer surprises" is at least laughable. Maven and its plugins have a lot of bugs and quirks that bring surprises in tonnes (and it as was pointed out in article itself and many of posts). And there are a few means to cope with them. Concerning of easy of use of Maven project in different IDEs (not from zour post, but anyway) - why m2eclipse are a mess for so long time? And supposedly best part of Maven - dependency management - in reality is not so good. Even products produced by established and well-organized teams suffer from it. E. g. Almost each new Spring release suffers from POM-related problems at least few days after release. Just check forum.springframework.org. And so on, and so on.

matt green replied on Wed, 2009/03/11 - 5:44am

@Adam wrote: 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.

I am able to load a NetBeans project from eclipse.  The only change? Make sure your eclipse output is
"build/classes".  If you create the project first in NetBeans then the Eclipse project creation wizard figures this out automatically.


 @Adam wrote: Maven is great if: 2. The developers are religious about their IDE and are using IntelliJ, NetBeans and Eclipse at the same time.

I don't use IntelliJ, but I would hope it is able to load a NB project.

As far as running in Eclipse and NetBeans, I have a small program that can expand the generated manifest entries from NetBeans into my output directories, and so yes I can debug NetBeans RCP applications in Eclipse just fine (if I want to).   I have even debugged JSF applications (designed in NetBeans) in Eclipse.

  @Adam wrote: Maven is great if: 3. You are building a product-like application. You will have to manage different versions and branches with their dependencies.

That's why we have API versioning, and it needs to be available and enforced at run time as well, hence ServiceProviders, and serviceLoaders.  NetBeans has modules that are loaded in their own classloader, so you can't circumvent it using reflection.  I don't use OSGi, but I think it solves some of the same problems.
Suggesting that it is an advantage to have this logic in Maven is not just zero value, it's negative value.
Now your team is (potentially) debugging Maven dependency logic that is duplicated in the NB Module System, or the OSGi platform, or the ServiceProvider / ServiceLoader mechanism of Java itself.
This may be addressed by JSR-294.  I any event, Maven can't address reflection issues, but a module system can.


  @Adam wrote: Maven is great if: 4. You project consists of several teams which work on dependent modules. These modules have to be composed to the application regularly.

Again, you need API versioning, this needs to be enforced at runtime (as well), and therefore we don't want the logic twice (once in NB Modules (or OSGi), and once (half enforced) by Maven).


   @Adam wrote: Maven is great if: 5. You plan to use checkstyle, pmd, generate a project website etc. It's easy with Maven.

I don't think the value add of these tools could possibly justify something with consequences so far - reaching as the adoption of Maven, IMO.
 

matt green replied on Wed, 2009/03/11 - 6:11am

@franzwong wrote: While modularity jumps into java, I think more people will demand for dependency solving.

 Try NetBeans modules, or OSGi.  If you can't use that, try using package protected members for controlling API access.  The public classes / interfaces are the public API.  Use factories to load an implementation.  If that's not enough, try: java.lang.reflect.Proxy
this can be used in conjunction with ClassLoaders to decouple a class from the other libraries at run time and strongly enforce modularity at the classloader level.

 

 

matt green replied on Thu, 2009/03/12 - 5:19am

>That's terribly misleading. That will only work if you have everything Maven depends on correctly configured. Then, once you do "mvn install" watch as your console fills up with a stream of unintelligible messages.

Exactly.  What's the point in Maven?  It's one of those non-sensical 3rd party packages beloved by turbo weenies and abhorred by professionals.

Jack Nicole replied on Sat, 2010/05/15 - 3:33am in response to: phil swenson

Thanks for posting , is great submit website

Jack Nicole replied on Sat, 2010/05/15 - 3:34am in response to: Grzegorz Borkowski

Thanks for the fine tips gregorz, jucarii

Carla Brian replied on Sat, 2012/06/02 - 11:40am

Maven allows a developer to comprehend the complete state of a development effort in the shortest period of time. Once you familiarize yourself with how one Maven project builds you automatically know how all Maven projects build saving you immense amounts of time when trying to navigate many projects. - Instant Tax Solutions Reviews

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.