Skip to main content

Simple things just work .... Ant 1.8

Posted by herkules on February 17, 2010 at 5:57 AM PST

I recently got pointed to that link:

I read the news with some pleasure reminding me that I still like Ant based builds very much over Maven in many cases.

Of course there are a lot of well maintained projects on the web that work very well with Maven. You never know how many enthusiasts-hours have been spent to make that happen. However, in smaller business projects I experienced the situation to be slightly different. Not a single one I came across ran out-of-the-box. Some actions had to be taken upfront, jars needed to be downloaded seperately, some repository got closed or moved away … and so on.

For the latest project of that kind I created an Ant based build which was really fun to do. It was so simple, fast, predictable, transparent. Together with the NetBeans' Ant environment including Ant debugger - fun!

Looking at the result, the build was fully canned, way faster (even with Ant 1.7 which is known to be slow now :)), the artifacts smaller. Everything is built right in place, no redundant copying of files which feels good from an esthetic point of view. The build.xml files are just a few lines and so much smaller than any pom.xml could ever be.

Interesting enough when monitoring the process: creating the Ant build from scratch took approximately the same time as bringing the Maven stuff to work.

I like the simple things.


Maven takes an initial investment

You're right about the manually installed JAR files and possible repository problems. That's what a company internal repo is for. Besides, Maven is _not_ (just) a build tool - dependency management is perhaps it's most important single feature. What's the point of using Maven, if you don't have an internal repository to publish your JARs to? So, Maven requires two initial investments (in terms of time, which in a business setting equals money): 1) setting up a repository and 2) user education.

I guess the sweet spot for Ant is somewhere between a very simple project (which Maven handles with almost zero effort) and a complex, multi-module project. In the latter case, the switch to Maven isn't really practical - the project needs to be Mavenized early on.

Personally I don't get people who complain about the verbosity of a Maven pom.xml. In a simple project it's 90% a stock POM with very little modifications, so why be bothered with it? And in the more complex cases, well, I'd love to see a build.xml doing compilation, packaging, test and code coverage reports etc. in less XML than a Maven POM. Besides, excessively big POMs can be combated with POM inheritance and modularization.

Most people who complain about Maven are either using it as a drop-in replacement for Ant, or simply don't know how to use it properly. For the latter, Maven project itself is partly to blame, since the documentation isn't exactly top notch. Luckily, there's "Maven: The Definitive Guide" (aka "The Maven Book") freely available:

To give an example...

To give an example, this the most complex build file for an OSGi bundle with jar- and other OSGi-bundle-dependencies. With this file, all the targets like build, jar, test, run are ready to go. Easy? Readable? I think so.


<?xml version="1.0" encoding="UTF-8"?>
<project name="manager" default="bundle" basedir=".">

    <description>Builds, tests, and runs the project ${} ${version}.</description>

    <!-- where to find the common ant build directory -->
    <property name="common.dir" value="../antbuild"/>

    <!--import common targets-->
    <import file="${common.dir}/common.xml"/>

    <!--build dependent projects-->
    <target name="build_dependencies">

        <declare_jar_dependency.macro        prjpath="../Registry"            jar="registry"/>
        <declare_jar_dependency.macro        prjpath="../RemoteServiceCall"    jar="remoteservicecall"/>
        <declare_bundle_dependency.macro    prjpath="../Carrier"            name="carrier"/>

        Define the projects compile classpath.
        Library paths can be found in antbuild/ for reference.
        <path id="project.classpath.refid">
            <pathelement    path="${registry.artifact}"/>
            <pathelement    path="${remoteservicecall.artifact}"/>
            <pathelement    path="${carrier.artifact}"/>

I couldn't agree more

I have to work daily with maven, and I am starting to have headaches just to imagine what would be the pom.xml version of your build.xml example :) The only thing that Maven has going for it is dependency management, but it brings a huge complexity with it. Plus its IDE integration, when comparing with Ant, leaves too much to be desired. There are lots of Maven features that just break Eclipse or Netbeans, when used.

Well, Maven is perfect for

Well, Maven is perfect for building modularized projects, dependency resolution (most of the time, you dont have to think about it, just add to pom and that's all). It _IS_ very easy with maven. But on the other hand, if you need something more complex, it becames aweful, because you need to write your own plugin or use ant tasks ) So i hope dynamic languages support in maven 3 will be the "killer feature" and they will drop a lot of boilerplate xml from poms. Will see )

I have used ant and maven in

I have used ant and maven in different projects. Both are powerful instruments, but one common thing in them that disturbs is xml. So when maven and groovy come together (maven 3?) i think it'll be more powerful instrument than maven 2 and ant 1.8

groovy ant builder

IIRC the Groovy Ant builder is right there :)