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:

• core tasks will use the same attribute names for common functionality
• similar tasks will be unified to use similar forms.
• different implementations for the same functionality will be hidden behind facade tasks.
• properties and data types will be unified so that they share the same namespace and inheritance rules. Need to talk about how ${} expansion works for filesets and so on.

Furthermore some things will have to become more explicit:

• remove all magic properties
• make build file writers explicitly state which filters/filtersets a copy task will use
• add scoping rules for properties so that not all of them will be inherited by sub-builds, only those that have been specified explicitly. Fill in details once they've been sorted out.

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).

Even though Ant installation already is quite simple in Ant1 (extract the archive and set two environment variables), alternative ways to install Ant like using Webstart or a "self-extracting" JAR file will be explored.

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).

Ant2 will provide a way to define tasks that itself can have tasks as child elements without knowing all defined tasks at compile time. Discussions on ant-dev usually talk about "container tasks" in this context.

The only way to "include" common XML snippets so far has been the usage of external SYSTEM entities, a mechanism that is tied to DTDs and doesn't mix well with alternative approaches like XML Schema. Ant2 will provide a built-in include mechanism.

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:

• Tasks written for Ant1 won't work in Ant2 as the API of Ant's core and the names of utility classes are going to change. There will probably be adaptors and utility classes to ease the transition for task writers.
• Build files written for Ant1 will probably not be valid in Ant2 or at least not yield the same results. It is expected that Ant2 will come with a tool to translate Ant1 build files into equivalent Ant2 versions
• magic properties like build.compiler may disappear and be replaced by a different customization concept.
• Ant2 is going to require a JDK version 1.2 or above and a JAXP compliant parser version 1.1 or above.
• If you specify more than one target in another target's depends attribute, Ant1 will execute these targets from left to right (as long as the dependency tree permits it) - Ant2 will not guarantee this behavior but will allow build file writers to specify the order explicitly.
• Dereferencing a non existent property a via ${a} will result in a build failure.

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:

• It will be possible to cancel a running build process.
• Ant will detach from System.err/.out/.in completely and communicate with the front-end via a well defined API. The front-end will have to handle user input for tasks that need it (tasks that ask for a password for example).
• Tasks will provide some way to identify their attributes from the outside. fill in details

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.

In Ant1 users have little control over how things work. There are a couple of magic properties to make Ant chose a preferred compiler or modify the CLASSPATH, but they are barely documented. If users want to set these properties for every build process, they have to learn the undocumented tricks of the ANT_OPTS environment variable or the ~/.antrc file.

Ant2 will have a well defined system to specify user preferences. This system will not only let user chose their compiler but also give them a chance to provide default values for attributes (say you always want the debug attribute of the javac task to be true - unless it has been disabled explicitly). Need to give details once they've been sorted out.

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?

Data Types

Ant1 supports a limited set of data types (fileset, patternset and path) and at least up to Ant 1.3 it is not possible to register custom data types without writing a task that does this. Ant2 will provide a built-in mechanism to define new data types.

Existing data-types will be improved, the files in a fileset can be chosen based on more than just pattern matching for example (modification time or permissions for example). Ant2 will have built-in tasks for set operations.

Data types and properties will share the same name space and follow the same scoping and precedence rules. ${} again.

Multi-Threading of Tasks Within a Target

It will be possible to run several tasks in parallel - these tasks will belong to the same target and all tasks will be joined at the end of the target.

Internationalization

Ant2 itself will provide internationalized (error) messages and provide utility classes to help task writers to do the same. These utility classes may very well come from a different (Jakarta) project.

Ant's primary language and the language of the build file will continue to be English.

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. Two very common reasons to reject something were, that the request has been too vague or the same functionality could already be provided by some other accepted new feature.

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].

Simple Flow-Control

People asking for these kind of things have often heard the standard "Ant shall not become yet another scripting language, Ant shall not fall into the same traps make/Perl did ..." response from the committers and some long-term ant-dev people.

The long version of that answer is:

• There are lots of open source scripting languages, there is no need to define a new one.
• Ant has been created to be a build tool. While you can use it for a whole lot of other things, this is not Ant's primary focus (and it shouldn't be). Most use-cases that ask for flow-control are out of Ant's scope.
• Ant already provides the requested functionality for many common situations. The execon and apply tasks can be used to iterate over a set of files as the (planed for Ant2) javaon and anton tasks will do.
• Providing flow-control inside Ant's core would increase the complexity of this core. This would make it difficult for new contributors to understand how Ant works and increase the maintenance cost for Ant at the same time. The goal of the Ant developers is to push as much complexity and functionality out of Ant's core into the tasks as possible.

That being said, Ant2 will make it easy to write iteration or conditional tasks via the new container task concept. We expect foreach, switch and if tasks to be written, but they will probably not become core parts of the Ant distribution.

Advanced Conditionals for if/unless Attributes

The argument here is the same as for flow-control. We are talking about complexity that can be pushed from the core to tasks - and that is what will be done. Instead of additional power for the if/unless attributes, Ant2 will have a new task that can set properties based on the values of other properties or logical combinations of other conditions, something like (making up syntax):

<condition name="javamail-complete">
  <and>
    <available class="javax.mail.Transport"/>
    <available class="javax.activation.DataHandler"/>
  </and>
</condition>

will become possible

Multi-Threaded Execution of Targets

The general feeling was, that the combination of target dependencies and multi-threading would soon become too complex, especially since Ant2 will allow people to explicitly enforce the order in which (independent) targets will be executed.

This issue will be explored again later, it has not been rejected for all time being, but it is out of scope for Ant 2.0

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.