Requested Features for Ant2
I. Things that don't affect the core but are requests for new tasks or
enhancements to existing tasks.
"Accepted" for a task doesn't mean that
task will be a core task (or even be supplied by a voter), just that having
it (as an optional task) would be acceptable.
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
(JikesImpl, ModernImpl, etc.).
(One candidate is
<jar>, with implementations for
<fastjar>, for example.)
Unify multiple similar tasks to use similar forms (eg., all the
Better scripting/notification support so the hooks are available to
send notifications at certain times.
<ant> task that will find build files according
to a fileset and invoke a common target in them. (
Add a JavaApply task that executes a given class with files from a
fileset as arguments (similar to
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.).
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
for network URLs.
Task to extract classes from a jar-file that a given class depends on.
<depend> or IBM's JAX, for example.)
into a more general
<condition> task support
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
During the discussion it became obvious that some things from this list
are goals for Ant and some should be guidelines for developers.
Therefore, there are two flavors, "Accepted" and
"Accepted As Guideline".
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).
Accepted As Guideline
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).
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
Allow user datatypes to be defined via a
IV. Things we probably agree on but need to discuss the details or
decide between several possible options.
"Accepted" means the goal/idea is fine, not that a decision on a
particular implementation has been made.
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
(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
(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
Allow documentation to be stored in
(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
something else has been specified).
(Three ideas so far: a CSS-like language,
<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
Detach Ant from
(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.
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.
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
Set-arithmetic for fileset/patternset/*set.
Inheritance of Ant properties/datatypes/context/etc. in project hierarchy.
Make all datatypes interfaces to allow them to be customized in many
Inheritance between Ant datatypes (ie., fileset A inherits from
fileset B (includes all entries in A).
Homogenize notion of PATHs and filesets.
Rejected (as a primary goal)
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
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.)
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.
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
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.
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"?)
Tasks provide some way to identify their attributes from the outside.
Possible solutions include a special method like
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).
"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.
Allow build-file writers to modify logging (verbosity, for example)
on a target-by-target or task-by-task basis.
Multi-threaded execution of tasks within the same target.
Multithreaded execution of targets.
Procedural versus purely declarative
Simple flow-control (
Targets should be like methods, including a return value.
Build-files should be purely declarative.
Ability to manage scoping of properties in general
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.
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
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.
Allow sequence to be specified in
<antcall> to work with current list of executed
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
Specify an OnFail task or target that runs in case of a build
if/unless attributes check for the value of a property, not
only its existance.
Check for more than one condition in
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.???]
VI. Things that were submitted late
Integration of the
Recursive property resolution (ie., resolving