Reference Document CSC India Pvt Ltd

A brief comparison of and

Maven and Ant are two complimentary build tools for Java. They both
have the ability to compile classes, run tests, and create distributions.

Ant
Ant is a java based build tool designed to replace Make. Builds are
driven by an xml document that describes how to manufacture project
artifacts (build.xml). It is a flexible, effective, solution that is by far the
most popular Java build tool. Ant, by itself, doesn’t have a facility for
reusing build knowledge; this is all encapsulated in the build.xml file.
Reuse is accomplished in Ant, by copying this file from project to
project and editing it to suit each use. Ant can be extended through
java classes and customized build instructions.

Maven
Maven is a build management and reporting tool intended to take Ant
to the next level. It is described as a project build and comprehension
tool for Java. Build goals are encapsulated in plugins so they can be
reused across projects. Reuse is achieved through the use of plugins
that become part of the Maven installation library. New plugins can be
made available for use by all projects. Maven enforces a ‘Best
Practices’ approach on the build process. This includes a standard
directory structure for source code, documentation, and other project
components. Maven tries to apply metadata with ‘sensible’ defaults to
describe a project so that bringing up a new project is as painless as
possible. One of the more useful aspects of Maven is the extensive
project reporting; Maven generates a website of project reports that
provide a snapshot of the project at any point in time.

What Ant enthusiasts say about Maven

Here are a few summarized comments culled from various blogs,
websites, forums and articles posted on the Internet.
• Maven is slow
• We don’t need another build tool. Maven doesn’t improve on Ant
• Maven is just Ant plus dependencies
• Maven is a set of Ant-scripted reusable plugins
• Ant can control the build details at the lowest level
• Sure it creates a web site, but the web site is ugly

Initial Version created by – Jegadeesan Danavelu

Reference Document CSC India Pvt Ltd

• Ant projects are ‘self contained’; they run on every system…

without a repository or Internet connection.
• I hate Jelly and the documentation sucks

What Maven enthusiasts say about Ant

Summarized comments culled from various blogs, websites, forums
and articles posted on the Internet.

• Have to understand all the details of how the tool works

• Sure the website is ugly, but its better than what I would build by
hand
• The build process is duplicated
• Maven allows me to start a new project, with a good build
process, quickly
• Want a system that already knows how to build reports, run
tests, build javadocs, jars/wars/ear, etc…
• Can override defaults or create custom operations by diving into
Ant when needed
• Maven is good at the high level, Ant is good at the low level.
Maven lets me use Ant when needed.
• Maven isn’t a substitute for Ant, it’s a way to simplify Ant use.
• Ant is powerful, but tedious. With Maven you don’t have to
repeat boiler plate code
• It’s like Ant on Steroids

The truth about Ant and Maven

The truth lies somewhere between the views of those in either camp.
Maven and Ant are really complementary tools. Many of Maven’s build
goals are based on Ant tasks. In fact, Ant can be invoked during the
Maven build process. Maven brings a lot of structure, discipline, and
cross project capabilities to the build management process.

The essential difference between the two tools is how they approach
the build. Ant wants the user to describe how to build the system,
while Maven wants the user to describe how the project is structured
so it can build the project. Both approaches are valid; it all comes
down to a matter of preference.

Driving the Build Process

• Ant build.xml files: The build files do have a somewhat cryptic
syntax. If you haven’t used it before it can be a bit tough to get
started. However, the documentation is quite good and there
are plenty of examples on the web.

Initial Version created by – Jegadeesan Danavelu

Reference Document CSC India Pvt Ltd

• Maven project.xml files: There can be certain amount of ugliness

that is exposed when using the Project Object Model (POM). If
you do not specify everything correctly, the error messages can
be than less than helpful. There is a definite learning curve, but
this will exist for any tool.

Setting up the Project

Maven tries to dictate the project directory structure while Ant
does not attempt to tell you how to do things. Some people will
like the order and consistency that Maven brings to
development, while others will prefer the freedom to do
whatever they want.

Build Performance
If you just want to build and run tests, they both appear to be
comparable in terms of performance. However, certain Maven
reports may take a while to generate. For example, the
jcoverage analysis report will compile and instrument the code
then run all unit tests in order to determine the line and branch
coverage for each class. All this analysis does take some time
and this is a case where some of the comparisons appear
unequal.

Customization
Both tools support customization by the developer. Neither is all
that easy to learn. Maven uses an XML scripting language called
Jelly along with Java to create custom plugins that can become
part of a shared plugin library. Ant allows the development of
custom build tasks, but does not provide as strong a facility for
sharing customizations.

Built in functionality
Since Maven uses Ant it inherits the ability to execute Ant build
scripts. Maven brings the ability to share common build
knowledge across many projects. The website generation and
extensive set of reports available in Maven are simple to
configure and provide a consistent view of projects.

A Simple Comparison

I'm only showing you this to illustrate the idea that, at the most basic level, Maven has built-in
conventions. Here's a simple Ant build file:

<projectname ="my-project"
default
="dist"
basedir="."
>

Initial Version created by – Jegadeesan Danavelu

Reference Document CSC India Pvt Ltd

<description
>
s imp le example bu i l d f i l e
</description
>

<!-- set global properties for this build -->

<propertyname ="src"location
="src/main/java"
/>
<propertyname ="build"location
="target/classes"
/>
<propertyname ="dist"location
="target"
/>

<targetname ="init"
>
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"
/>
</target
>

<targetname ="compile"depends="init"
description
="compile the source> "
<!-- Compile the java code from ${src} into ${build} -->
<javacsrcdir
="${src}"destdir
="${build}"
/>
</target
>

<targetname ="dist"
depends="compile"
description
="generate the distribution"
>
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"
/>

<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file

-->
<jarjarfile basedir="${build}"
="${dist}/lib/MyProject-${DSTAMP}.jar" />
</target
>

<targetname ="clean"
description
="clean up">
<!-- Delete the ${build} and ${dist} directory trees -->
<deletedir="${build}"
/>
<deletedir="${dist}"
/>
</target
>
</project
>

Initial Version created by – Jegadeesan Danavelu

Reference Document CSC India Pvt Ltd

In this simple Ant example, you can see how you have to tell Ant exactly what to do. There is a
compile goal which includes the javac task that compiles the source in the src/main/java directory
to the target/classes directory. You have to tell Ant exactly where your source is, where you want
the resulting bytecode to be stored, and how to package this all into a JAR file. While there are
some recent developments that help make Ant less procedural, a developer's experience with Ant
is in coding a procedural language written in XML.

Contrast the previous Ant example with a Maven example. In Maven, to create a JAR file from
some Java source, all you need to do is create a simple pom.xml, place your source code in
${basedir}/src/main/java and then run mvn install from the command line. The example Maven
pom.xml that achieves the same results.

<project
>
<modelVersion>4 .0 .0</modelVersion>
<groupId>org . sona type .mavenbook</groupId>
<artifactId
>my-pro jec <
t /artifactId
>
<version
>1 .0</version
>
</project
>

That's all you need in your pom.xml. Running mvn install from the command line will process
resources, compile source, execute unit tests, create a JAR, and install the JAR in a local
repository for reuse in other projects. Without modification, you can run mvn site and then find an
index.html file in target/site that contains links to JavaDoc and a few reports about your source
code.

Admittedly, this is the simplest possible example project. A project which only contains source
code and which produces a JAR. A project which follows Maven conventions and doesn't require
any dependencies or customization. If we wanted to start customizing the behavior, our pom.xml
is going to grow in size, and in the largest of projects you can see collections of very complex
Maven POMs which contain a great deal of plugin customization and dependency declarations.
But, even when your project's POM files become more substantial, they hold an entirely different
kind of information from the build file of a similarly sized project using Ant. Maven POMs contain
declarations: "This is a JAR project", and "The source code is in src/main/java". Ant build files
contain explicit instructions: "This is project", "The source is in src/main/java", "Run javac against
this directory", "Put the results in target/classses", "Create a JAR from the ....", etc. Where Ant
had to be explicit about the process, there was something "built-in" to Maven that just knew
where the source code was and how it should be processed.

High-level Comparison

The differences between Ant and Maven in this example?

Ant...

Initial Version created by – Jegadeesan Danavelu

Reference Document CSC India Pvt Ltd

• Ant doesn't have formal conventions like a common project directory structure, you have
to tell Ant exactly where to find the source and where to put the output. Informal
conventions have emerged over time, but they haven't been codified into the product.
• Ant is procedural, you have to tell Ant exactly what to do and when to do it. You had to tell
it to compile, then copy, then compress.
• Ant doesn't have a lifecycle, you had to define goals and goal dependencies. You had to
attach a sequence of tasks to each goal manually.

Where Maven...

• Maven has conventions, it already knew where your source code was because you
followed the convention. It put the bytecode in target/classes, and it produced a JAR file
in target.
• Maven is declarative. All you had to do was create a pom.xml file and put your source in
the default directory. Maven took care of the rest.
• Maven has a lifecycle, which you invoked when you executed mvn install. This command
told Maven to execute the a series of sequence steps until it reached the lifecycle. As a
side-effect of this journey through the lifecycle, Maven executed a number of default
plugin goals which did things like compile and create a JAR.

Initial Version created by – Jegadeesan Danavelu