Requested Features for Ant2

I. Things that don't affect the core but are requests for new tasks or enhancements to existing tasks.

  Accepted

Add a new datatype filterset to group token-filters.

Make usage of particular filters/filtersets explicit in copy tasks.

Make facade tasks for things like <javac> (JikesImpl, ModernImpl, etc.). (One candidate is <jar>, with implementations for a <fastjar>, for example.)

Unify multiple similar tasks to use similar forms (eg., all the <javacc>-type tools).

Obfuscating task.

Better scripting/notification support so the hooks are available to send notifications at certain times.

Add an <ant> task that will find build files according to a fileset and invoke a common target in them. (<anton>?)

Add a JavaApply task that executes a given class with files from a fileset as arguments (similar to <apply>).

Include some more sophisticated loggers with the Ant distribution – especially for sending emails. Make the existing one more flexible (stylesheet used by XmlLogger). (Could be part of the same module tasks would be developed in?)

Better docs (eg., more examples, tutorials, beginner documents, reference sheets for tasks, printable version, etc.).

RPM task.

Task for splitting files (head/tail/split-like functionality).

Task to create XMI from Java.

Socksified networking tasks, SSH tasks. (Peter Donald expressed some legal concerns that might need to be overcome, depending on the implementation.)

A reachable task that works much like <available>, for network URLs.

Task to extract classes from a jar-file that a given class depends on. (Based on <depend> or IBM's JAX, for example.)

Unify <available> and <uptodate> into a more general <condition> task – support AND/OR of several tests here. (Will need more discussion because of vote by Peter Donald.)

JSP-compilation task. (Sounds like a candidate for a facade task.)

URL-spider task that checks links for missing content or server errors.

Make the default logger's output clear, informative, and terse. (Rejectors think it already is.)

Add an attribute to <property> to read in an entire file as the value of a property.

Make PATH-handling consistent. Every task that has a PATH attribute must also accept references to PATHs.

II. Goals that need to be abstract until we get into design decisions.

  Accepted

Provide a clear mission statement for Ant.

Main goals: simplicity, understandability, extensibility.

Remove magic properties if at all humanly possible.

Remove as much dependency on native scripts as possible.

Clean object model (ie., Project/Target/Task).

Good event model to integrate well with IDE/GUI/etc.

Use a consistent naming scheme for attributes across all tasks.

Keep build-file syntax as compatible to Ant1 as possible (ie., don't break something just because we can).

Keep the interface for tasks as similar to that of Ant1 as possible (ie., don't break something just because we can).

Ant should be cancelable.

No commit of new features without documentation.

No commit of new features without test-cases.

III. Things that are simple and easy to implement, where we expect the committers to agree.

Namespace support so different concerns can occupy different namespaces from Ant (thus, SAX2/JAXP1.1).

Java2

Remove all deprecated methods, attributes, tasks.

Allow all datatypes to be defined anywhere (ie., as children of project as well as of target).

Make properties fully dynamic (ie., allow their value to be reassigned).

Unify the namespace of all data types (ie., properties + filesets + patternsets + filtersets).

Add a user-defined message if a target will be skipped as a result of the specified if/unless.

Allow user datatypes to be defined via a <typedef> similar to <taskdef>.

IV. Things we probably agree on but need to discuss the details or decide between several possible options.

  Accepted

The ability for GUI/IDE tools to integrate easily with object model without reinventing the wheel and writing their own parser (which Antidote was forced to do). (Two suggested solutions were allowing GUI developers to extend the object model (ie., GUITask extends Task) or to have Task as an interface (ie., GUITask implements Task). This way, the GUI tasks could be W3C DOM elements, have property vetoers/listeners, etc.)

Support for numerous front-ends – from command-line over GUI to servlets. (Corollary of the above?)

Fully interpreted at run-time. (This almost requires some form of abstraction/proxy that stands in place of tasks till it is interpreted. This can be hash-tables/simple DOM-like model/whatever.)

Provide utility classes to aid in building tasks (ie., like <uptodate> functionality abstracted). (Need to become more specific here.)

Make ant-call a low-cost operation so it can do certain optional/template-like operations. (Corollary of "fully interpreted at run-time"?)

Allow facilities to build projects from multiple sources (ie., CSS+XML, XSLT+XML, Velocity+text or database, from inside jars or normal build.xml files, etc.) (Allow the project tree to be built dynamically.)

Move to a system that allows docs to be generated – doc snippets should be included with the tasks they document. (Which DTD? Which tools for generation?)

Allow tasks to be loaded from jars. (Use either an XML file in TSK-INF/taskdefs.xml or a manifest file.)

Allow documentation to be stored in .tsk jars. (Corollary of the above two points?)

Separate tasks into .tsk jars somehow. (Decide on categories. Probably via function – ie., java tasks, file tasks, EJB tasks, etc.)

Make having separate build-files easy (à la AntFarm) and importing different projects a breeze.

Provide support for user-defined task configurations – (ie., give users the ability to specify a default value for attributes (eg., always use debug="true" in <javac> unless something else has been specified). (Three ideas so far: a CSS-like language, a <taskconfig> element, or properties following a specific naming scheme.)

Support more control over the properties that are going to be passed to subprojects (modules).

Task to prompt for user input. (Does affect core, as we need a means to request input from the front-end.)

Add CVS login feature. (Requires handling of user input.)

Easier installation process. GUI, maybe webstart from the homepage. This includes asking the user whether he wants to use optional tasks and downloads the required libs, automatic upgrades and so on. Self-extracting jar installer:
    java -jar jakarta-ant-1.3-bin.jar
Prompts for destination directory, extracts archive, fixes all text files with <fixCRLF> task; on UNIX, makes scripts executable. Could also modify ant scripts with the location of ANT_HOME.

Logo for Ant.

Detach Ant from System.err/.in/.out. (Beware of problems with spawned processes.)

Build-files should be declarative in nature.

It should be possible to modify details of the actual build (e.g. classpath, compiler used, etc.) without the need to change the build specification. (Do build.compiler and build.sysclasspath cover everything, or do we need to add more stuff like this?)

Better sub-project handling (whatever that means in detail).

V. Things we probably don't agree on.

  Accepted

Allow <include>/<exclude> to work with multiple characteristerics of a file (ie., include into fileset if file is readable, modified after 29th of Feb, has a name that matches the pattern "**/*.java" and the property foo.present is set. Something similar to:

  <include>
    <item-filter type="name" value="**/*.java"/>
    <item-filter type="permission" value="r"/>
    <!-- could optionally be directory or some other system specific features -->
    <item-filter type="type" value="file"/>
    <item-filter type="modify-time"
                 operation="greater-than" 
                 value="29th Feb 2003"/>
  </include>

Provide support for non-hardwired (ie., loadable) low-level components (mappers/itemset-filters/converters). Allow them to be loaded in either globally or via a new classloader.

Provide support for non-hardwired (ie., loadable) converters.
Q: What is a converter? Is this an implementation detail?
A: Not an implementation detail, but a way to extend the engine to convert more datatypes. Currently, we have a fixed set that is expanded on occasion (ie., includes primitive types + File). Instead of spreading converting code throughout the tasks, it can be centralized into one component and used by the engine. This becomes particularly relevent if you build Ant-based testing systems and use Ant in certain web-related areas.

Set-arithmetic for fileset/patternset/*set.

Inheritance of Ant properties/datatypes/context/etc. in project hierarchy.

Allow mappers to be genericized so that particular features can be modified during mapping. Something similar to:

  <fileset ...>
    <include name="*.sh"/>
    <mapper type="unix-permissions">
      <param name="user" value="ant"/>
      <param name="group" value="ant"/>
      <param name="mod" value="755"/>
    </mapper>
  </fileset>

Provide datatypes through property tag and remove need for separate free-standing entities. That is:

  <property name="foo">
    <fileset dir="blah">
      <include name="*/**.java" />
    </fileset>
  </property>

Make all datatypes interfaces to allow them to be customized in many ways.

Inheritance between Ant datatypes (ie., fileset A inherits from fileset B (includes all entries in A).

Homogenize notion of PATHs and filesets.

  Accepted

Provide support for CJAN.
Q: In what way?
A: Probably by supplying a set of tasks that download versioned binaries and their associated dependencies, caching the downloads in a known place and updating binaries when required. ("When required" being indicated by a change in property values).

Make it possible to re-use the task engine for other things (ie., Installshield-type app, Peter's cron-server, and other task-based operations).

  Rejected

Force resolution of classes on loading, to identify class-loader issues early (at least in global classloader).

Ignore any classes contained in the damned ext dirs of a JVM – possibly by launching with something like:
    jar -Djava.ext.dir=foo -jar ant.jar
(Accepted if optional.)

Workspace/sub-build issues

  Accepted

Create the concept of workspace so that projects can be built in a DAG and thus enable projects like Catalina/Tomcat to have an easy build process. It also helps CJAN to a lesser degree and would partially solve the jars-in-CVS thing.

Allow a target to depend on a target in another build-file.

  Rejected

Project inheritance. (What's this?)

Target inheritance. That is, the ability to include targets from other project files, overriding them as necessary (so, cascading project files).

Add an attribute to <ant> to feed back the environment (properties and taskdefs) from the child build to the parent.

Allow a target to reference properties defined in another build-file.

Documentation system

  Accepted (with no decision on which system to use)

Generate docs by Anakia/XSLT. (Corollary of "move to a system that allows docs to be generated"?)

Task API

  Accepted

Tasks provide some way to identify their attributes from the outside. Possible solutions include a special method like getProperties(), an external describing file shipping with the task class or special Javadoc comments parsed by a custom doclet. Whatever the method, it should not impose any cost on run-time, as it is only used a small percentage of the time (design-time).

Provide "failonerror"-like functionality to all tasks. (Provide this as an aspect?? Much like logging aspect or classloader aspect).

Tasks should have access to its own XML representation.

Task level if and unless attributes.

Allow tasks to find out, whether another task has completed successfully.

Logging

Allow build-file writers to modify logging (verbosity, for example) on a target-by-target or task-by-task basis.

Make loggers configurable via build.xml.

Multi-threading

  Accepted

Multi-threaded execution of tasks within the same target.

Multithreaded execution of targets.

Procedural versus purely declarative

  Rejected

Simple flow-control (if-then-else, for)

Targets should be like methods, including a return value.

Build-files should be purely declarative.

Properties

  Accepted

Ability to manage scoping of properties in general (ie., target/project/workspace).

Templates

  Rejected

It should be possible to provide general/(template?) build specifications, and to declare, for a concrete item, that it should be built according to such a general specification.

XML issues

  Accepted

A built-in mechanism to include build-file fragments – something that doesn't use SYSTEM entities at all and therefore is XSchema-friendly, allows for property expansions, etc.

Allow Ant to farm out attributes and elements that are not in the Ant namespace to other components (ie., hand doc: elements to the Documentation component or log: attributes to the Log policy component, etc.

Let Ant ignore – but warn – if unknown XML elements or attributes occur in a build-file.

Core extensions

  Accepted

Allow sequence to be specified in "depends" attribute, or enhance <antcall> to work with current list of executed targets.

Provide a way to define the order in which targets that a given target depends upon get executed. (Same as above?)

Support nesting tasks into other elements – not just as children of target – as proposed by Thomas Christen in his mail message.

Define task contexts that define various common aspects (logging, failure handling, etc.), and assign them to tasks.

Allow named tasks to be defined by <script> elements.

Specify an OnFail task or target that runs in case of a build failure.

Make if/unless attributes check for the value of a property, not only its existance.

Check for more than one condition in if/unless attributes.

Organization

  Rejected

Separate CVSes and code hierarchies for:

• task engine [org.apache.task.*]
• project engine (ie., model of targets/projects/workspaces) + support/utility classes [org.apache.ant.*]
• core tasks (ie., tasks supported by Ant contributors) [org.apache.???]

Miscellaneous

  Accepted

Internationalization.

VI. Things that were submitted late

  Rejected

Integration of the <depend> and <javac> tasks.

Recursive property resolution (ie., resolving ${dist.${name}.dir})