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
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 is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Geertjan Wielenga replied on Tue, 2009/02/17 - 3:25am
What about Groovy's Ant support? Very cool. You should look at it:
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-groovy.html
bhaskar vk replied on Tue, 2009/02/17 - 4:24am
Maven fits the bill for some of your ANT use cases you mentioned as well.
Let's dive a bit deep
The maven artifact plugin now supports catalogs that can be used to qucikly prototype projects of various types.
See this blog entry for details.
Netbeans has a very nice maven plugin that supports maven projects natively in Netbeans. Compared to the horrible horrible m2eclipse mess. The maven plugin was one of the primary reasons I move from eclipse to netbeans. Seriously m2eclipse is such a mess, compared to Netbeans+maven.
Again I fail to see how ANT is superior here. Maven supports modularization , but doesn't enforce it. You can easily build stand alone projects/libraries with maven.
Another not so discussed advantage of maven I see over ANT, is that it is gentle on the SCM. With ANT you end up uploading all your binary JARs in to the SCM. (Something SCM was never meant to do). While with maven I can use a repositoy manager to host and manage all my JARs, and have only my source code in SCM, the way it should be.
David Sills replied on Tue, 2009/02/17 - 6:21am
One question I've never had the option of asking: what about those of us who see an EJB/Web project as a single "thing", with separate Java folders for the contents of the EJB-jar and WAR files? (We don't think of an EJB project and a separate Web project as a practical solution for this issue.)
The single-Java source structure is fine for simple cases, but doesn't meet this one, which in my experience is very common. I have been unable to rationalize trying Maven despite a considerable degree of interest in it for this very reason.
Isn't this a case (a reasonably common one, I should think) that Maven should address? Or are JEE and Maven at odds, at least for this type of project?
Thanks in advance for all thoughtful answers.
David Sills
Raphael Miranda replied on Tue, 2009/02/17 - 7:11am
Well most of the work is already done.
Gradle = Groovy + Ant(Gant) + Ivy + Conventions
nikojava replied on Tue, 2009/02/17 - 8:12am
fortknox replied on Tue, 2009/02/17 - 10:00am
in response to: vkbhaskar2.myopenid.com
jordanz replied on Tue, 2009/02/17 - 2:59pm
>Maven or Ant?
Neither. My IDE is my build environment.
franzwong replied on Wed, 2009/02/18 - 5:04am
While modularity jumps into java, I think more people will demand for dependency solving.
nithril replied on Wed, 2009/02/18 - 7:16am
Gradle seems to meet the best of the two.
It solves the lake of flexibility and readability of Maven with the lake of convention of Ant.
fabio.canepa@gm... replied on Wed, 2009/02/18 - 7:21am
in response to: fortknox
Jeroen Wenting replied on Wed, 2009/02/18 - 9:00am
in response to: jordanz
phil swenson replied on Wed, 2009/02/18 - 10:22am
XML based builds are an abomination. XML was not intended to be a scripting language. Even the guy who created Ant says using XML was a mistake. Is there a more awkward way to do a conditional or a loop than XML? Even variables are a pain in XML.
XML works for really simple things, but soon degrades into a freaking mess. I've seen the pattern repeated over and over.
This sort of problem is what scripting languages are for.
The real quesiton is whether to use Gant, Gradle, Buildr, or use JRuby Rake with the AntWrap gem (my favorite).
mgira replied on Wed, 2009/02/18 - 10:25am
in response to: davidsills
Maven and JEE are not add odds, in fact they work really well together.
Just try the maven-archetype-j2ee-simple archetype.
Martijn Verburg replied on Wed, 2009/02/18 - 12:42pm
in response to: davidsills
Hi David,
A way to deal with this in Maven is to use a multi module project and the assembly plugin. Just visit the assembly plugin document for details.
jordanz replied on Wed, 2009/02/18 - 3:26pm
in response to: jwenting
Our project is multi-million lines of code and thousands of Java files. Our build team uses simple scripts to build the application and it's very reliable and repeatable. For my day-to-day development, IntelliJ IDEAm is excellent at building/debugging the app. I have no need for ANT/Maven (yes, I've used both).
jordanz replied on Wed, 2009/02/18 - 4:34pm
in response to: philswenson
Excellent point.
mgira replied on Wed, 2009/02/18 - 4:56pm
in response to: jordanz
jordanz,
what do you need a "build team" for?
With Maven this would be a one liner:
mvn install
that could be easily done by an CI Server.
Russel Winder replied on Thu, 2009/02/19 - 8:38am
James Law replied on Thu, 2009/02/19 - 9:23am
FWIW, I find using the maven ant tasks to be the perfect combination.
You get the dependency management, but without having to understand the many maven conventionsand the full flexibility of ant to do build/test execution.
jordanz replied on Thu, 2009/02/19 - 4:13pm
in response to: mgira
>what do you need a "build team" for?
Any large project is going to have someone responsible for building the project. We have 1.5 people on our "build team".
>mvn install
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.
In any event, our build is a one line of command. It runs a purpose built script that builds the application.
Peter Karich replied on Thu, 2009/02/19 - 5:37pm
What about build performance?
I mean, Maven is slow compared to ant!
What do you do in maven to fix this problem??
Is there a work around? I am working with NetBeans ....
mgira replied on Fri, 2009/02/20 - 3:49am
>> Any large project is going to have someone responsible for building the project. We have 1.5 people on our "build team".
Why not automate this with a CI Server?
> > That's terribly misleading. That will only work if you have everything Maven depends on correctly configured.
Why misleading? "Correctly configured" is the way things are supposed to be,
>> Then, once you do "mvn install" watch as your console fills up with a stream of unintelligible messages.
"Build failed" or "Build successful"are imho pretty self explanatory, the rest is nothing more than a status message of what Maven2 is doing.
>> In any event, our build is a one line of command. It runs a purpose built script that builds the application.
Oh well, at least we can agree that this is a good thing.
Personally i would never Script Builds again, be it with Ant, Groovy or whatever, since i find that configuring a build like with Maven2 is a much more straightforward approach, but to each his own.
@ Peter
>> I mean, Maven is slow compared to ant!
>>What do you do in maven to fix this problem??
ime Maven2 is as fast as Ant, have you changed your Memory settings on Netbeans (/etc/netbeans.conf)?
Peter Karich replied on Fri, 2009/02/20 - 3:47pm
in response to: mgira
Do you mean a 'clean and build' with maven2 is fast as ant's 'clean and build'?
On my system the first one taks 8 or more seconds. The latter one is 1 or maximal two ...
I don't think it has anything to do with NetBeans, because it is the same for the command line call 'mvn install'.
But I would like to try your config changes. What should I do?
Mike P(Okidoky) replied on Fri, 2009/02/20 - 11:47pm
I really dislike Maven because almost always when I've downloaded a source project that uses Maven to build, it just didn't work. Always some sort of excuse. Version this, dependency that.
I think ant is the one defacto stable method to build Java projects. What I do is I define my projects in very concentrated xml project fies, and run it through a bunch of xsl files to generate the build.xml file. Then I include the generated build.xml in my distribution. Works every time and is completely fool proof.
Viraf Karai replied on Sat, 2009/02/21 - 4:15pm
in response to: jordanz
Eugene Kuleshov replied on Sun, 2009/02/22 - 9:00am
in response to: vkbhaskar2.myopenid.com
The m2eclipse is not ideal, but can you please elaborate what mess exactly you are referring to in m2eclipse? So, we both on the same page. Thanks
Liam Knox replied on Sun, 2009/02/22 - 9:14pm
in response to: jordanz
jordanz replied on Mon, 2009/02/23 - 3:21am
>So your "custom build script" essentially replicates Ant tasks or Maven goals like dependencies,
No - that stuff may be necessary to you, but it isn't for us. You make it sound like Java is unusable without these third party tools.
>Also your build team essentially re-invented the wheel by hand-crafting unit test execution
We don't do unit testing - but that's a separate subject.
>What did your build team find so hard about not standardizing around Ant or Maven?
That's like the old joke "Have you stopped beating your wife?". You're assuming that standardizing on these tools is necessary. It isn't.
>Also, are your "custom build scripts" cross platform i.e. run on Windows, Mac, and Linux?
We only deploy to one platform, so this is irrelevant.
jordanz replied on Mon, 2009/02/23 - 3:24am
>Clearly XML has suceeded very well as a configuration format and a data distribution format
Actually, I don't think it's succeeded very well at all. But, that's another subject.
>So you have '1 little line for your build', tell me, do you have another
>little line for your testing and another little line for you deployments?
Testing is done by Q/A group - where it should be. Deployment is done using the tools provided by our Application Server - as it should be.
Brian Pontarelli replied on Tue, 2009/02/24 - 2:57pm
Seems like everyone is leaving out Savant. Savant 2.0 provides conventions and downloadable plugins (ala Maven) that are Ant scripts and also offers dependency management. Anyone looking for another solution should check it out.
Savant 2.0 will also provide the concept of global plugins that can be written in any scripting langauge for the JVM (via Apache BSF). These can be run outside of a project to perform tasks like project creation and the like. They'll be executed like this:
$ svnt savant:make-project
We are also hoping to continue work on supporting a full build tool where the plugins can be written in any scripting language, can be downloaded, and support conventions as well as adhoc builds.
Anyone interested in checking it out or helping develop Savant should check out our project over at Google Code here:
http://code.google.com/p/savant-build