How to compare maven and ant ?

Apache Ant

• Ant doesn’t have formal conventions like a common project directory structure or default behav- ior. 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 have to tell it to compile, then copy, then compress.
  
• Ant doesn’t have a lifecycle. You have to define goals and goal dependencies. You have to attach a sequence of tasks to each goal manually.
  
  

Apache Maven

• Mavenhasconventions.Itknowswhereyoursourcecodeisbecauseyoufollowedtheconvention. Maven’s Compiler plugin put the bytecode in target/classes, and it produces 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 was invoked when you executed mvn install. This command told Maven to execute a series of sequential lifecycle phases until it reached the install lifecycle phase. 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. 
  

0. Maven has built-in intelligence about common project tasks in the form of Maven plugins. If you wanted
   to write and execute unit tests, all you would need to do is write the tests, place them in ${basedir}/src/test/java, addatest-scopeddependencyoneitherTestNGorJUnit,andrunmvn test.Ifyouwantedtodeploya web application and not a JAR, all you would need to do is change your project type to war and put your docroot in ${basedir}/src/main/webapp. Sure, you can do all of this with Ant, but you will be writing
   the instructions from scratch. In Ant, you would first have to figure out where the JUnit JAR file should
   be. Then you would have to create a classpath that includes the JUnit JAR file. Then you would tell
   Ant where it should look for test source code, write a goal that compiles the test source to bytecode, and execute the unit tests with JUnit. 
   

Without supporting technologies like antlibs and Ivy (even with these supporting technologies), Ant has the feeling of a custom procedural build. An efficient set of Maven POMs in a project which adheres to Maven’s assumed conventions has surprisingly little XML compared to the Ant alternative. Another benefit of Maven is the reliance on widely-shared Maven plugins. Everyone uses the Maven Surefire plugin for unit testing, and if someone adds support for a new unit testing framework, you can gain new capabilities in your own build by just incrementing the version of a particular Maven plugin in your project’s POM.
The decision to use Maven or Ant isn’t a binary one, and Ant still has a place in a complex build. If your current build contains some highly customized process, or if you’ve written some Ant scripts to complete a specific process in a specific way that cannot be adapted to the Maven standards, you can still use these scripts with Maven. Ant is made available as a core Maven plugin. Custom Maven plugins can be implemented in Ant, and Maven projects can be configured to execute Ant scripts within the Maven project lifecycle.