Comparing Maven to Ant

Maven is one of them tools that I always felt I should be using but for some reason I could never quite get into it. over the years I’ve made several attempts at reading their getting started guide but for some reason I was never really able to grasp what it was that made it better or more worthwhile than Ant.

The itch finally got to me again the other day so I had another go at it. This time round everything seemed to make much more sense. I don’t know weather it was because the documentation was more complete or because I was more familiar with the problems it was trying to solve but either way it seems be to finally starting to sink in.

The first feature I read about was the Standard Directory Structure. How many times have you created an Ant build file with the same targets again and again, i.e. clean, compile, test, jar, etc? Maven takes the very sensible approach that if you have the same directory structure for each of your projects then why bother with a build file at all. By accepting Maven’s Standard Directory Structure (which is pretty much your average project directory structure) it will automatically give you all these standard targets (or goals as Maven calls them).

The next feature that caught my attention was the default inclusion of resources. Resources here are things like properties files, basically anything that isn’t a JAR file. In the Ant world you’d normally keep these in your src folder and then copy then over to your build folder as part of the compile target. Well in Maven the Standard Directory Structure saves you having to do any extra configuration. All you need to do is drop your resource files into a special “resources” directory alongside your source code directory. The contents of this directory will be automatically included in any classpath or JAR file that’s created during the development cycle.

One of the Maven’s biggest features is it’s ability to automatically import external dependencies (JAR files) into your project. I’ve always questioned the logic of including or not including JAR files within a project’s source control system. One part of says that source control is for source only and that external dependencies don’t change so they shouldn’t go into source control. Over the past few years though the realist in me has come to appreciate the simplicity of using source control to hold JAR files as well. You don’t need to give each developer instructions on where to go to get all the dependent JAR files (and risk the introduction of incorrect versions). Maven’s solution to this problem gives you the best of both worlds. Basically, rather than including your JAR files in source control you just tell Maven what JAR files your project depends on. This is done in a file called pom.xml (Project Object Model). It’s like a build.xml file but really it’s more of a description of your project that Maven can use to carry out it’s goals. When you run Maven it will automatically go to a given URL ( by default), download all the JAR files your project needs and include them in your classpath. It’s that simple. Oh and it caches the JARs locally so the next time you run Maven on your project it won’t have to download them again.