If something looks like this, this is either a request for input or a "REVISIT" marker or similar.

Ant2 Goals

Even though Ant2 is expected to be incompatible with the current Ant1 series, it still has the same goals. Ant is a Java based build tool and this remains the main focus of it. The original goals of simplicity, understandability and extensibility still stand and Ant2 will try to achieve them even better than Ant1 does.

Simplicity and Understandability

These two goals are closely related. Ant build files shall be easy to read and understand - at the same time it should be easy to write a custom Ant task and to use the utility classes that Ant2 provides.

Ant2 shall be more consistent than Ant1 is - this means:

Furthermore some things will have to become more explicit:

The front-ends for Ant2 shall be smart enough to automatically detect the required libraries (like tools.jar), the use of native scripts shall be kept to a minimum.

Build file writers can attach a message to targets that will be presented to the user if that target is going to be skipped (based on the if/unless attribute of the target).

Extensibility

Ant2 like Ant1 uses build files written in XML as its main input, but it will not be restricted to it. The core of Ant2 will work on an object model of Project/Target/Task that is independent of any external representation.

As an extension of the current <taskdef> concept, tasks can be bundled into task libraries (together with data types and other utility classes). These task libraries are special JAR archives that somehow describe the contained tasks to Ant. Ant will automatically know all tasks contained in task libraries that have been placed into a special directory - in addition task libraries can be referenced and used in a build file explicitly. Fill in details once they've been sorted out.

It has become apparent, that several "aspects" of tasks are so common that task writers find themselves duplicating code all over again - things like classpath handling or "do we stop the build if this task fails?" functionality for example. Ant2 will provide a way to let the user attach an "aspect handler" to a project - all attributes that live in a certain namespace are going to be passed to this handler. Need to talk about TaskContext here.

Ant2 will farm out common functionality from tasks into utility classes so that task writers can benefit from a tested and stable framework - they shouldn't need to deal with existing tasks directly (like some tasks "abuse" the <touch> task in Ant1).

New/Modified Features

Ant2 will run the build process fully dynamically, which means that task won't be instantiated before they are actually being run and ${} expansion will see the very latest value of a property. It will be possible to reassign values of properties via a built-in task.

Compatibility with Ant1

Ant2 is going to break Ant1 in several ways:

Support Integration of Ant Into Other Tools

Ant2 will have a clear separation between the front-end that is responsible for user interactions, the object model that represents the project to build and the part of Ant that runs the build process itself Name that TaskEngine, ProjectEngine, ExecutionEngine or what?. This separation is expected to ease the integration of Ant (or parts of it) into other products.

Ant2 itself will include a command line front-end and Antidote will become the GUI front-end to it. Other front-ends like a servlet front-end are expected outside of Ant's core as well.

In addition to this separation, the following features should help people who want to integrate Ant into their products:

More Control for Users and Build File Writers

Ant2 will use a BuildListener concept similar to the one of Ant1 but may provide a richer set of events. It will be possible to attach and detach listeners to a build process from within the build file and to modify the behavior of attached listeners.

Documentation System

All tasks will be documented in XML files using a common DTD Still need to define it - task libraries are expected to include the documentation using this DTD inside the library itself.

Better Subbuild Handling

Is there something beyond "should become better" right now?

Rejected Features

This is list is not complete, it just highlights some of the rejected features and tries to explain why they've been rejected.

For a complete listing of all requested features, see requested-features.html. The discussion on all topics can be followed in the archives for ant-dev in threads starting from 2001-03-21 - the subject lines contained either [VOTE] or [DISC].

Ideas for New Tasks and Tools

Please refer to requested-features.html in the section "I. Things that don't affect the core but are requests for new tasks or enhancements to existing tasks." for this.


$Id$

Copyright © 2001 Apache Software Foundation. All rights Reserved.