Summary
The Apache Ant project released the first beta of the 1.7 version of Ant. The new version introduces a resource framework, as well as antlibs, a framework that makes it easier to create and distribute custom Ant tasks. A new tool for Ant task unit testing is provided as well.
Advertisement
The Apache Ant project released the first beta of Ant 1.7. The new version provides several additions to the capabilities of this popular build tool for Java and .NET.
The first notable new feature is a resource framework:
Some of the core ant tasks such as <copy/> are now able to process not only file system resources but also zip entries, tar entries, paths... Resource collections group resources, and can be further combined with operators such as union and intersection. This can be extended by custom resources and custom tasks using resources.
The second new Ant 1.7 feature is antlib, a new framework of building and packaging Ant tasks. In a recent OnJava article, Ant 1.7: Using Antlibs, Kev Jackson describes antlib as the tool that fixes the deficiencies of the previous taskdef task descriptions:
The antlib feature allows developers of Ant tasks to ship fixes and updates independently of the main Ant distribution... An antlib is simply a collection of classes bundled with an XML descriptor file. Typically, an antlib is distributed as a .jar file, but this isn't a strict requirement. The root element of the XML file is . Any classes can go into the makeup of an antlib, but only some classes can be declared in the antlib.xml file.
Another new Ant 1.7 feature comes in the form of an antlib, AntUnit. This Ant task lets you create unit tests for Ant tasks without having to use the JUnit API.
What are your methods of managing third-party or custom Ant tasks? Do you think that antlib will solve the problem of incrementally updating custom tasks?
> <p>What are your methods of managing third-party or custom > Ant tasks? Do you think that <em>antlib</em> will solve > the problem of incrementally updating custom tasks?</p>
Antlib support has been in ant1.6.5; we have just been refining things for Ant1.7.
By declaring an xmlns for a library, xmns:ac=antlib://net/sf/antcontrib ; ant will autoload the library and make its tasks, types and macros availalable in the new namespace. This does mean that you have to deal with xmlns, but it stops problems with every app server stack providing a task called <deploy>. Now you can have <tomcat:deploy> next to <glassfish:deploy>.
If you are writing third party libraries for ant, write and ship an antlib today, just by adding a new descriptor, antlib.xml. And what is the format of that? Its a subset of ant's own language, with <taskdef>, <typesef>, <presetdef> and <macrodef> being the current set of allowed tasks.
There's one problem with antlibs right now, is that all this automatic stuff works if the new lib dirs are on the classpath. For ant on the command line, you can use the -lib option, or stick stuff in ~/.ant/lib. For IDEs you need to force it on. Otherwise you need to use a typedef command, something like
Incidentally, a new version of Java Development with Ant is due this autumn, in sync with Ant1.7. Expect lots of coverage on antlibs and antunit, which is simply wonderful.
-Steve Loughran Member of the Ant development team Author of Java Development with Ant, 2nd edition
Previous Topic
