Article: Ant 1.6 Features for Big Projects

Discussions

News: Article: Ant 1.6 Features for Big Projects

  1. Stefan Bodewig, Ant contributor and a member of the project management committees of the Apache Ant, Gump, and Jakarta projects, discusses new features of Ant 1.6 and how they might impact the way you structure your build process.

    Introduction
    While the 1.5.x series of Ant releases brought a lot of improvements at the task level, it didn't change the way people used Ant. With Ant 1.6, things are a bit different. Several new features have been added to support big or just complex build scenarios. But to fully leverage their power, users may need to restructure their build process a little.

    This article focuses on three of the new features — <macrodef>, <import>, <subant> tasks — to show you what you may gain by using them and how they may impact the way you'll be structuring your build setup.
    Read Article: New Ant 1.6 Features for Big Projects

    More on Java at the OTN's Java Developer Center

    Threaded Messages (2)

  2. In That Vein[ Go to top ]

    Not to self-promote, but my article on the subject has finally seen the light of day at JDJ. Pretty similar in that it focuses on the new features of Ant 1.6, in particular those elements that help to make build files more managable.
  3. I agree, Ant 1.6 features finally make it possible to create well-structured complex build files. To the features Stefan mentions, I would add target name overriding as an important new feature because it allows you to define a standard set of targets while changing the behavior as needed for each build project. For example, if you have a distribution target that compiles and packages your code like this:

    <target name="dist" depends="compile, jar"/>
    <br/>

    And you want to have unit tests run before you package up the distribution, you can override the 'dist' target like thus:


    <target name="dist" depends="compile, junit, jar"/>
    <br/>

    It isn't quite OO for Ant, but it comes close.
    Maintaining a standard set of target names is important for usability as Ant scripts become more complex.

    To get the most flexibility out of this technique I follow two rules of thumb: The first is to leave the bodies empty on the standard targets. This enables you to add or remove behavior more easily in the overriding target. The second trick is to keep the dependencies to a minimum in the supporting (non-standard) targets and instead define them in the standard targets. For example, this:


    <target name="compile" depends="javac" description="standard target"/>
    <target name="javac" depends="copy.resources" description="supporting target"/>
    …
    </target>
    <target name=" copy.resources" description="supporting target">
    …
    </target>
    <br/>

    is less flexible than this:


    <target name="compile" depends="javac, copy.resources" description="standard target"/>
    <target name="javac" description="supporting target"/>
    …
    </target>
    <target name=" copy.resources" description="supporting target">
    …
    </target>
    <br/>

    because you can disable the copy.resources target without overriding the supporting javac target.

    For an extensive example of using Ant 1.6 features for building and testing complex J2EE applications, see the open-source JAM - JavaGen Ant Modules framework.