Skip to main content

Maven for Ant Users

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.

Comments

Sheldon said…
This comment has been removed by a blog administrator.
This comment has been removed by the author.
Sheldon said…
This comment has been removed by a blog administrator.
This comment has been removed by the author.

Popular posts from this blog

3D Photo Viewer for Looking Glass

The Looking Glass I created my first Chrome extension, which is now live on the Chrome Web Store ! It's built for the Looking Glass , a holographic display that let's you view three-dimensional objects without glasses. I've also opened the source to the extension on GitHub. The Chrome extension allows you to view Facebook's "3D Photos", a feature they added in 2018 for displaying photos that include a depth map like those from phones with dual cameras, such as Apple's "Portrait Mode". Getting Started To use the extension, connect your Looking Glass to your computer, navigate to Facebook and open the viewer from the extension's popup menu. This will open a browser window on the Looking Glass display's screen in fullscreen mode. Opening the Viewer Once the viewer is open, the extension watches for any 3D Photo files being downloaded, so browse around Facebook looking for 3D Photos.  I recommend some of the Facebook groups de

Simplifying logging with Maven and SLF4J

UPDATE: Ceki commented below which prompted me to rewrite the third paragraph. UPDATE 2: I have a better way of configuring Maven and SLF4J now. The mismatch between logging frameworks always seems to come up in projects I've developed over the years. Little-by-little I've learned and relearned how to navigate the nest of runtime logging that occurs in non-trivial applications. With my latest project I think I finally converged on a solution that I'll carry forward to future projects. So what am I really talking about? Have you ever been stumped, even for a short time, about where a certain log message is going and why it might not appear in your log? Often this happens when you are trying to debug an issue with a third-party library that's using a different logging implementation them your application. If you are nodding from familiarity, skip the next paragraph. Let's start from the beginning. There are several logging implementations available for Java, th

Simplifying logging with Maven and SLF4J (Part 2)

So in my  previous post  I explained how to simplify your logging with Maven and SLF4J. If you haven't read it yet, please do before reading more.  Since then I've discovered an easier and cleaner way to remove the secondary frameworks from your Maven dependency tree. Here's a revised overview of the steps: Decided which logging framework will be your primary, aka who will actually write to your log file. Define the dependency scope of all the secondary frameworks to be ' provided '. Configure your project to depend on drop-in replacements of each secondary framework from SLF4J. Define secondary frameworks as provided Use the dependencyManagement section for this. Its used when you might have a dependency transitively. Add dependency on SLF4J Add the following to your pom.xml Conclusion So now in only 3 steps you can redirect all your logging to your primary logging framework without changing a line of code!