Maven or Ant?

Question

Back up your claim with some actual benefits.

Answer 1

Its not either/or.

Ant is a build tool, a powerful one but still just a build tool.

Maven is a project oriented build manager that handles the build but also manages dependencies and artifacts, etc. Ant has a variety of tasks for handling Maven projects and repositories, because you will still use Ant when using Maven.

Answer 2

Ant is powerful build tool similar to make or nmake.Maven on the other hand is Apache project builded to overcome the shortcomings of Ant.Really speaking Ant is powerful build tool whereas Maven is little newer in this aspect

Answer 3

Building with Ant is likely to become complicated over time. Ant requires for instance scripting in XML. XML is not a nice structure to develop in.

Maven is not a silver bullet. (You might still need Ant.) But it is easier to maintain. It's most obvious advantage is managing 3rd party libraries.

If only Maven was better documented... :-(

Answer 4

Contrary to what @Joe Skora has said, with Maven 2 I have rarely needed to use ant in combination with Maven. Maven 1 was built on top of ant, so you often found yourself dropping down into ant related things. I rarely have, however, with Maven.

These are the reasons I advocate Maven:

• Repeatable builds / Dependency Management. All it takes is a check out of your source and, if necessary, a Maven configuration file, and you can issue one command and all of the dependencies for your project will be downloaded and then the project will be built. No checking of binary jars into your source control, or manually copying things, or whatever. Also, it handles transitive dependencies. If you depend directly on one library, you don't have to list its dependencies as well. Maven automatically figures that out for you.
• Versioned artifacts This is an extension of the above point. Any given Maven project is required to have a version number. When you deploy built resources to your internal Maven repositories, it is easy to point to any given version. After getting used to this method of development, it doesn't make sense to me any longer to not have versions of both the built artifacts and its dependencies when doing development.
• Convention and configuration over scripting. Maven has set conventions for project layout. It constructs classpaths based upon your declared dependencies and their transitive dependencies. With ant, you have to explicitly write out XML "code" for the steps to compile, to construct jars, to set up your classpaths, etc. Maven is much more declarative.
• IDEs Yes, many ides have Ant integration or are based upon ant. Yet, I find that many people who use ant built scripts tend to check in IDE project files (.project for Eclipse, for example) into source control. This is often bad because of pathnames and so forth. With Maven, out of the box you can generate project files for Eclipse and IDEA, and I believe these as well as other major IDEs can import Maven projects. No need to check configuration files into source control.

Those are my main reasons for advocating Maven. However, as others have noted, it is far from perfect:

• The documentation is lacking in places.
• Sometimes you have to do silly things to work around bugs in the dependency calculation mechanism.
• It can be slow at times (though I hear this is being worked on).

The declarative dependency management and version artifacts alone have got me sold on Maven.

Answer 5

Maven has the chance to hit the sweet spot between a scripted build tool and an IDE-style pure declarative build. In the core of Maven is the build lifecycle, which is just an abstract sequence of steps. Then, in your POM you define (or inherit) a packaging. The packaging defines a set of default plugins and executions. You can think about the plugins as a bunch of Ant-tasks (or 'goals' in mavenspeak), which are versioned together. The executions define parameters for the actual goal and are bound to a lifecycle phase.

See also these two blog articles (shameless self promotion).

Answer 6

We chose Maven 2 last year for one reason:

Ant is a build tool; Maven is a build system

What this means is that with Maven, you don't need to decide your directory layout, build targets, versioning scheme, management of dependencies, etc. This is all designed for you. It also means you will be working against the tool somewhat if you don't like the default.

The benefits are that most of the common tools you want to build into your build system (CheckStyle, FindBugs, Unit Testing, Unit Coverage, JDepened...) are all available without any additional development work. In addition, there is a well-defined framework for extending the build system by building plugins (btw - using Ant to build plugins is trivially easy). Also, there is nice integration with IDEs so that developers are using the same build information as the auto-build system.

The trade-off is that unless you are starting from scratch, you will probably need to refactor your source code to be in line with what Maven expects. The trade-off for not having to build everything from scratch is that you sometimes spend time figuring out how to coax Maven to do what you want, how you want it done.

If I was starting from scratch again today, I would definitely go with Maven again (after 1+ year experience).

Answer 7

I prefer Maven over Ant because of...

• Dependency mangement
  • less jar hell
  • automatically downloads what you need over the internet
• Convention over configuration
  • Fixed project structure is the same across all your projects
  • If you follow the convention you need to configure very little in your scripts.
  • Very good plug-in support. Lots of things for code coverage, testing, deployment and more
• Ant get's really complex with multimodule builds and deployment whereas it's sort of built-in to maven.

With all that said, I recommend that you do not use Eclipse with Maven. The Eclipse project structure is one of peers (it's flat) whereas maven uses a hierarchy (it's a tree). Trying to shoehorn your project into the eclipse format gets messy.

The Netbeans and Intellij IDEA, both have excellent maven support.

Philosophically speaking you might say that with maven you tell it what you want to accomplish and with ant you tell it how you want it to be done.

Answer 8

I have used both Ant and Maven (1 and 2), and I strongly encourage avoiding Maven (see what others are saying).

By using them, I mean that I have used, maintained, and created build scripts for dozens of clients and hundreds of projects, of all shapes and sizes. Neither Ant nor Maven scale well, so keep your build scripts independent (one project = one artifact at a time).

However, Ant leaves you in control, but Maven will fight you forever unless you bend to its will (it's way or the highway).

Best wishes.

Answer 9

Having just moved to an Ant project from many painful Maven projects, I was hoping for dumbed-down but simple builds with ant - unfortunately, the build environment at my new gig is a massive proprietary can-o-worms, as I'm sure most Ant-based projects become over time.

At least Maven forces you to do things consistently, and to give credit, it goes a whole lot further towards providing a useful build environment than ant ever did. Ant falls short in delivering the tools to create a build environment by miles.

I now understand why there's no good Ant plugin for Eclipse - it's all proprietary, so there's nothing consistent that a plugin (or human) can assume about an ant build, unlike maven, where everything is either explicitly defined, or implicitly follows convention.

With not much to choose from, I would go with Maven again, but I'd recommend reading this first: 10 Sure Signs You Are Doing Maven Wrong

Most of my maven frustrations have been caused by engineers who were tasked with setting up the maven build system and thought they knew better than to RTFM and follow convention.

Answer 10

-comment deleted -