Agile Zone is brought to you in partnership with:

Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

Ant 1.8 Scanning Leaves 1.7.1 in the Dust

02.09.2010
| 12364 views |
  • submit to reddit
The classic Java build tool, Apache Ant, just reached its next GA version update.  Ant 1.8 has improved directory scanning performance and better symbolic link cycle handling.  Dramatic improvements have been achieved when scanning large directory trees.  Version 1.8 also brings enhancements and bug fixes to many tasks and types (a strong point for Ant) as well as some core changes.

With more than 275 fixed Bugzilla issues, Ant 1.8 flaunts some new performance improvements.  A large directory scan, which would have taken 14 minutes in Ant 1.7.1, now takes as little as 22 seconds with Ant 1.8.  The new version also scans smaller directory trees faster, going roughly from quadratic time to linear time when scanning directories.

Ant 1.8 includes a handful of new elements including  <extension-point>,  a new top-level element that assists in writing reusable build files that are meant to be imported.  Its name and dependency-list are similar to <target> and it can be used like a <target> from the command line or a dependency-list but in addition, the importing build file can add targets to the <extension-point>'s depends list.

In Ant 1.7.1, you would write something like this:
imported.xml:
<project name="imported"...>
...
<target name="setup">
...
</target>
<target name="compile" depends="setup">
...
</target>
</project>

importing.xml
<project ...>
...
<import file="imported.xml">
<target name="setup" depends="imported.setup">
... stuff that should happen before compile ...
</target>
</project>

In Ant 1.8, you would instead write it like this:
imported.xml:
<project name="imported"...>
...
<target name="setup">
...
</target>
<extension-point name="ready-to-compile" depends="setup"/>
<target name="compile" depends="ready-to-compile">
...
</target>
</project>

importing.xml
<project ...>
...
<import file="imported.xml">
<target name="pre-compile" extensionOf="ready-to-compile">
... stuff that should happen before compile ...
</target>
</project>

The method for extending Ant's property expansion algorithm has been rewritten (breaking the older API) in order to be more powerful and easier to use.  The new API can implement the entire local properties mechanism and it can be implemented in a separate library without changing Ant's core.  Things like props Antlib, which hasn't been released yet, can now provide frequently required "scripty" fuctions without touching Ant itself.

Other additions include:

  • New lexically scoped local properties.
  • An enhanced <import> that can import from any file or URL resource.
  • An easier mechanism for extending Ant's property expansion.
  • A new task called include that provides a preferred alternative to <import> when you don't want to override any targets.
  • Rewritten if and unless attributes that do what is expected when applied to a property expansion (i.e. if="${foo}" means "yes, do it" if ${foo} expands to true.  In Ant 1.7.1 it would mean "no" unless a property named "true" existed).  This adds "testing conditions" to property expansion as a new use-case.

Ant 1.8 now requires at least Java 1.4 or later.  For a full list of changes, follow this link.

Comments

matt inger replied on Tue, 2010/02/09 - 2:09pm

If you look hard enough, you can combine this new release with ivy, and get some nice, out of the box modularized build sharing.  I'll assume here that you've got Ivy 2.1 installed into your Ant distribution.  You would then need to create a re-usable build script, and package it up into a jar file, and deploy it to a maven or ivy repository, and have an appropriately configured ivysettings.xml file.

<project name="my-project" basedir="." default="compile"  xmlns:ivy="antlib:org.apache.ivy.ant">

  <ivy:settings  file="ivysettings.xml" />

  <ivy:cachepath inline="true"
                 organisation="com.myorg.build"
                 module="build-scripts"
                 revision="latest.release"
                 pathid="build-scripts.path" />
  <import>
    <javaresource classpathref="build-scripts.path" name="build.xml" />
  </import>


</project>

You've got an instant re-usable build package. It gives you enforceable build structure, script re-use across source repositories, etc....

If your build package has other resources, you'll have to be smart about how you refer to them from within your re-usable build.xml, as they will all be <resource> references, rather than file references.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.