ant/docs/ant2/requested-features.txt

List of requirements for Ant2 split into categories. 

If you disagree with the category something has been put into, speak
up.

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

* 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 fastjar
  for example.

* unify multiple similar tasks to use similar forms (ie all the javacc
  type tools)

* Obfuscating task

* Add an <ant> task that will find build files according to a fileset
  and invokes 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?

* make the default logger's output clear, informative, and terse.

  Actually, this is a little bit abstract, but doesn't apply to the
  core either.

* Better docs.

  More examples. Tutorials, beginner documents, reference sheets for
  tasks, printable version.

* RPM task.

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

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

* Task to create XMI from Java.

* socksified networking tasks, SSH tasks.

* a reachable task that works much like available for network URLs.

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

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

* Integration of the depends task and javac tasks

* jsp-compilation task

  Sounds like a candidate for a facade task.

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

II. Abstract goals that need to be abstract until we get into design
decisions.
======================================================================

* Provide a clear mission statement for Ant.

* Main goals: Simplicity, Understandability, Extensibility

  Simple and understandable for the target audience - developers,
  build-engineers ...

* 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/whatever

* use a consistent naming scheme for attributes across all tasks

* keep build file syntax as compatible to Ant1 as possible -
  i.e. don't break something just because we can.

* keep the interface for Tasks as similar to the one of Ant1 as
  possible - i.e. don't break something just because we can.

* Ant should be cancelable

* no commit of new features without documentation (ouch 8-)

* no commit of new features without testcases

III. Things that are simple, 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 - i.e. as children of
  project as well as of target.

* make properties fully dynamic, i.e. allow their value to be reassigned

* unify the namespace of all data types (ie properties + filesets +
  patternset + filtersets).

* add a user defined message if a target will be skipped because the
  if/unless attribute says so.

* allow user-datatypes to be defined via a <typedef> similar to <taskdef>.

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

* 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
  object model (ie GUITask extends Task) or to have Task as interface
  (ie GUITask implements Task). This way the GUI tasks could be W3C
  DOM Elements, have property vetoers/listeners etc.

* support for numerous frontends - from command line over GUI to servlets

  corollary of the above?

* Fully interpreted at runtime. This almost requires some form of
  abstraction/proxy that stands in place of tasks till it is
  interpreted.  This can be hashtables/simple dom-like model/whatever

* provide utility classes to aid in building tasks. ie like up-to-date
  functionality abstracted

  Need to become more specific here.

* make ant-call a low cost operations so it can certain
  optional/template-like operations

  corollary of "fully interpreted at runtime"?

* allow facilities to build projects from multiple sources. ie CSS+xml
  or XSLT+ XML or Velocity+text or database or from inside jars or normal 
  build.xmls 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. tasks should be indicated by
  either xml file in TSK-INF/taskdefs.xml or manifest file.

* allow documentation to be stored in .tsk jars

  corollary of the two points above?

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

  Which hooks and where?

* separate tasks into .tsk jars somehow. (Probably via function - ie
  java tasks, file tasks, ejb tasks).

  Decide on categories.

* make separate build files easy (ala AntFarm) and importing different
  projects a breeze

* provide support for user defined task configurations - i.e. give
  users the ability to specify a default value for attributes (always
  use debug="true" in <javac> unless something else has been
  specified). 

  Three ideas so far: a CSS like language, a <taskconfig> element,
  properties following a specific naming scheme.

* support more control over the properties that are going to be passed
  to subprojects (modules)

* Ask for a new CVS module for Ant tasks.

  We need to define rules for this to work - maybe the rules proposed
  for the commons project could give us a start.

* It should be possible to modify details of the actual build (e.g. classpath,
  used compiler) 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?

* Task to prompt for user input.

  Does affect core as we need a means to request input from the Frontend.

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

* better subproject handling

  Whatever that means in detail.

* build files should be declarative in nature

V. Things we probably don't agree on. 
======================================================================

 * Allow mappers to be genericised 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>

 * Allow include/exclude tow 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 patter "**/*.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>

  2003 is no leap year 8-)

* provide datatypes through property tag and remove need for separate free
  standing entities. ie
  <property name="foo">
    <fileset dir="blah">
     <include name="*/**.java" />
    </fileset>
  </property>

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

 * force resolution of classes on loading to identify classloader 
 issues early. (At least in global classloader).

* 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

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

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

* 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 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 runtime as it is only used a small 
  proportion of the time (design-time).  

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

* Multithreaded execution of tasks within the same target.

* Multithreaded execution of targets.

* Project inheritance

  What's this?

* Target inheritance. ie The ability to include targets from other 
  project files overidining 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.

* Ability to manage scopping of properties in general (ie target/project/workspace).

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

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

* 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 Log policy component etc

* specify an onfail task or target that runs in case of a build
  failure.

* allow sequence to be specified in depends attribute or enhance
  antcall to work with current list of executed targets

* Support nesting tasks into other elements - not just as children of
  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 all datatypes interfaces to allow them to be customized in many
  ways.

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

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

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

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

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