My coworker asked me to describe how Maven compares and differs to Ant. I realized how hard it was for me to describe what a developer gets for moving their build process from Ant scripts to Maven. I can't make the argument that you can do X with Maven but not with Ant because I don't really have a valid example. However, I am inclined to make the argument that you can do X with both but with Maven it's easier.
With Maven, you collect metadata about your project instead of writing scripts defining the steps your build will take. For example, if you look at an Ant script you'll immediately see that it is organized as targets which many developers use to define and group the steps of their build process. In a Maven POM file, you won't see similar build steps defined. This can be confusing for a new Maven user coming from the world of Ant. I know it was for me. Instead, you'll see lots of metadata about the project such as dependencies, Maven plugins to use, locations for the source control repository and project website, the working directory structure, contributors and more, but nothing that defines what should happen when you want to build the project's jar, or generate a documentation site for the project. These steps are defined by various Maven plugins.
Maven plugins are the most tangible thing you get from using Maven over Ant. What the plugins provide are nothing you can't do with Ant, but they encompass many of the tasks Ant users have written and rewritten time and time again. Goals like compiling your classes, running your unit tests, jaring your classes, generating javadoc, building a JAR of your source files, and on and on. So if you want to build your project with Generics support, you'll define in your Maven POM file that the compiler plugin should target JDK 5.0, but you won't have to define what Maven needs to do to complete the goal.
So when it comes time to build your project, you haven't spent anytime rewriting goals, instead you've only spent time describing how your project differs from other projects. So when you call "mvn jar:jar" instead of "ant jar", you won't have written any of the boilerplate script to tell Ant how to build a jar and which steps it depends on (compile, test), you'll just have reused the jar goal that a Maven developer wrote.
With Maven you get to focus on the high-level task of defining your project instead of the low-level task of defining your build.
With Maven, you collect metadata about your project instead of writing scripts defining the steps your build will take. For example, if you look at an Ant script you'll immediately see that it is organized as targets which many developers use to define and group the steps of their build process. In a Maven POM file, you won't see similar build steps defined. This can be confusing for a new Maven user coming from the world of Ant. I know it was for me. Instead, you'll see lots of metadata about the project such as dependencies, Maven plugins to use, locations for the source control repository and project website, the working directory structure, contributors and more, but nothing that defines what should happen when you want to build the project's jar, or generate a documentation site for the project. These steps are defined by various Maven plugins.
Maven plugins are the most tangible thing you get from using Maven over Ant. What the plugins provide are nothing you can't do with Ant, but they encompass many of the tasks Ant users have written and rewritten time and time again. Goals like compiling your classes, running your unit tests, jaring your classes, generating javadoc, building a JAR of your source files, and on and on. So if you want to build your project with Generics support, you'll define in your Maven POM file that the compiler plugin should target JDK 5.0, but you won't have to define what Maven needs to do to complete the goal.
So when it comes time to build your project, you haven't spent anytime rewriting goals, instead you've only spent time describing how your project differs from other projects. So when you call "mvn jar:jar" instead of "ant jar", you won't have written any of the boilerplate script to tell Ant how to build a jar and which steps it depends on (compile, test), you'll just have reused the jar goal that a Maven developer wrote.
With Maven you get to focus on the high-level task of defining your project instead of the low-level task of defining your build.
Comments