Maven or Ant?
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:
- You are working with many "creative" developers. It will be hard to establish a defined project structure etc. without tool support.
- The developers are religious about their IDE and are using IntelliJ, NetBeans and Eclipse at the same time.
- You are building a product-like application. You will have to manage different versions and branches with their dependencies.
- You project consists of several teams which work on dependent modules. These modules have to be composed to the application regularly.
- 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:
- "Situational Software" which has to be developed quickly (in a few weeks / months).
- Projects with external dependencies which are working with "cutting edge" libraries. There is no need for finer grained dependency management.
- 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...
- Legacy projects which do not fit the Maven conventions very well. Violating Maven conventions may become a hassle.
- 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
(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
Oleksandr Alesinskyy replied on Wed, 2009/02/25 - 7:41am
in response to:
Edwin Quita
matt green replied on Wed, 2009/03/11 - 5:44am
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
Jack Nicole replied on Sat, 2010/05/15 - 3:34am
in response to:
Grzegorz Borkowski
Carla Brian replied on Sat, 2012/06/02 - 11:40am