Return-Path: 
 <ant-dev-return-11934-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 1641 invoked by uid 500); 26 Mar 2001 07:56:46 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 1618 invoked by uid 500); 26 Mar 2001 07:56:46 -0000
Delivered-To: apmail-jakarta-ant-cvs@apache.org
Date: 26 Mar 2001 07:56:46 -0000
Message-ID: <20010326075646.1598.qmail@apache.org>
From: bodewig@apache.org
To: jakarta-ant-cvs@apache.org
Subject: cvs commit: jakarta-ant/docs/ant2 requested-features.txt

bodewig     01/03/25 23:56:45

  Modified:    docs/ant2 requested-features.txt
  Log:
  group requests
  
  Revision  Changes    Path
  1.54      +113 -69   jakarta-ant/docs/ant2/requested-features.txt
  
  Index: requested-features.txt
  ===================================================================
  RCS file: /home/cvs/jakarta-ant/docs/ant2/requested-features.txt,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- requested-features.txt	2001/03/22 23:52:41	1.53
  +++ requested-features.txt	2001/03/26 07:56:45	1.54
  @@ -251,6 +251,9 @@
   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 @@
                   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 @@
       </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 @@
     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 @@
     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 @@
     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 @@
       [ org.apache.ant.* ]
     - core tasks (ie tasks supported by ant contributors) [ org.apache.??? ]
   
  -* check for more than one condition in if/unless attributes.
  +[DISC] misc
  +-----------
   
  -* 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.