@@ -251,6 +251,9 @@ decide between several possible options.
V. Things we probably don't agree on.
======================================================================
[DISC] Datatypes
----------------
* Allow mappers to be genericised so that particular features can be modified
during mapping. Something similar to
@@ -279,8 +282,6 @@ V. Things we probably don't agree on.
value="29th Feb 2003"/>
</include>
2003 is no leap year 8-)
* provide datatypes through property tag and remove need for separate free
standing entities. ie
<property name="foo">
@@ -289,45 +290,90 @@ V. Things we probably don't agree on.
</fileset>
</property>
* provide support for non-hardwired (ie loadable) low-level
components (mappers/itemset-filters/converters). Allow them to be
loaded in either global or 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 data types. Currently we have fixed set that is
expanded on occasion (ie includes primitive types + File). Instead
of spreading converting code through out tasks it can be centralized
into one component and used by engine. This becomes particularly
relevent if you build ant based testing systems and use ant in certain
web-related areas.
* Make all datatypes interfaces to allow them to be customized in many
ways.
* Set arithmetic for fileset/patternset/*set
* inheritance of ant properties/datatypes/context etc in project hierarchy
* inheritance of between ant datatypes. ie fileset A inherits from fileset B (includes
all entries in A).
* Homogenize notion of PATHs and filesets.
[DISC] Ant's goals
------------------
* make it possible to reuse taskengine for other things. ie
Installshield type app, Peter's cron-server and other task based
operations.
* provide support for non-hardwired (ie loadable) low-level
components (mappers/itemset-filters/converters). Allow them to be
loaded in either global or a new classloader.
* 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).
[DISC] class loading
--------------------
* force resolution of classes on loading to identify classloader
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
[DISC] workspace/subbuild issues
--------------------------------
* 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.
* provide support for CJAN
* Project inheritance
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).
What's this?
* provide support for non-hardwired (ie loadable) converters.
* Target inheritance. ie The ability to include targets from other
project files overidining them as necessary (so cascading project
files).
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 data types. Currently we have fixed set that is
expanded on occasion (ie includes primitive types + File). Instead
of spreading converting code through out tasks it can be centralized
into one component and used by engine. This becomes particularly
relevent if you build ant based testing systems and use ant in certain
web-related areas.
* Add an attribute to <ant> to feed back the environment (properties and
taskdefs) from the child build to the parent.
* Allow a target to depend on a target which is in another buildfile.
* Allow a target to reference properties defined in another buildfile.
[DISC] documentation system
---------------------------
* generate docs by anakia/XSLT
Corollary of "move to a system that allows docs to be generated"?
[DISC] Task API
---------------
* tasks provide some way to identify their attributes from the
outside.
@@ -337,42 +383,58 @@ V. Things we probably don't agree on.
should not impose any cost on runtime as it is only used a small
proportion of the time (design-time).
* 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.
* provide failonerror like functionality to all tasks. (Provide this as an aspect??
much like logging aspect or classloader aspect).
[DISC] logging
--------------
* allow build file writers to modify logging (verbosity for example)
on a target by target or task by task basis.
* Simple flow control (if-then-else, for)
* Make loggers configurable via build.xml.
[DISC] multithrading
--------------------
* Multithreaded execution of tasks within the same target.
* Multithreaded execution of targets.
* Project inheritance
[DISC] procedural versus purely declarative
-------------------------------------------
What's this?
* Simple flow control (if-then-else, for)
* Target inheritance. ie The ability to include targets from other
project files overidining them as necessary (so cascading project
files).
* targets should be like methods including a return value
* Add an attribute to <ant> to feed back the environment (properties and
taskdefs) from the child build to the parent.
* build files should be purely declarative
[DISC] Properties
-----------------
* Ability to manage scopping of properties in general (ie target/project/workspace).
[DISC] Templates
----------------
* 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.
[DISC] XML issues
-----------------
* 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 ...
* Make loggers configurable via build.xml.
* tasks should have access to its own XML representation.
* Allow named tasks to be defined by <script> elements.
* Let Ant ignore - but warn - if unknown XML elements or attributes
occur in a build file.
@@ -380,6 +442,11 @@ V. Things we probably don't agree on.
namespace to other components. ie hand doc: elements to the Documentation
component or log: attributes to Log policy component etc
[DISC] core extensions
----------------------
* Allow named tasks to be defined by <script> elements.
* specify an onfail task or target that runs in case of a build
failure.
@@ -390,15 +457,19 @@ V. Things we probably don't agree on.
target - as proposed by Thomas Christen in
<http://marc.theaimsgroup.com/?l=ant-dev&m=98130655812010&w=2>.
* Task level if and unless attributes.
* Make if/unless attributes to check for the value of a property, not
only its existance.
* Make all datatypes interfaces to allow them to be customized in many
ways.
* check for more than one condition in if/unless attributes.
* Allow tasks to find out, whether another task has completed successfully.
* provide a way to define the order in which targets a given target
depends upon get executed.
* Make if/unless attributes to check for the value of a property, not
only its existance.
* define task contexts that define various common aspects (logging,
failure handling ...) and assign them to tasks.
[DISC] organization
-------------------
* separate CVSes and code hierarchies for
- task engine [ org.apache.task.* ]
@@ -406,35 +477,8 @@ V. Things we probably don't agree on.
[ org.apache.ant.* ]
- core tasks (ie tasks supported by ant contributors) [ org.apache.??? ]
* check for more than one condition in if/unless attributes.
* provide failonerror like functionality to all tasks. (Provide this as an aspect??
much like logging aspect or classloader aspect).
[DISC] misc
-----------
* internationalization
* 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
* Set arithmetic for fileset/patternset/*set
* inheritance of ant properties/datatypes/context etc in project hierarchy
* inheritance of between ant datatypes. ie fileset A inherits from fileset B (includes
all entries in A).
* Homogenize notion of PATHs and filesets.
* build files should be purely declarative
* provide a way to define the order in which targets a given target
depends upon get executed.
* Allow a target to depend on a target which is in another buildfile.
* Allow a target to reference properties defined in another buildfile.
* targets should be like methods including a return value
* define task contexts that define various common aspects (logging,
failure handling ...) and assign them to tasks.
Stefan Bodewig