requested-features.txt

apache-ant-1.6.0-bin.zip 做jsp开发过程要用到的源码！

  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.

  [ACCEPTED]

* Logo for Ant.

  [ACCEPTED]

* detach Ant from System.err/.in/.out.

  Beware of problems with spawned processes.

  [ACCEPTED]

* better subproject handling

  Whatever that means in detail.

  [will need more discussion because of vote by Conor MacNeill]

  [REJECTED - vetoes by Conor MacNeill and Stefan Bodewig]

* build files should be declarative in nature

  [ACCEPTED]

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

 [REJECTED - vetoes by Stefan Bodewig and Conor MacNeill, not enough
             positive votes anyway.]

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

 [ACCEPTED]

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

  [REJECTED - only one +1 vote]

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

  [ACCEPTED]

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

  [ACCEPTED]

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

  [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]

* Set arithmetic for fileset/patternset/*set

  [ACCEPTED]

* inheritance of ant properties/datatypes/context etc in project hierarchy

  [ACCEPTED]

* inheritance of between ant datatypes. ie fileset A inherits from fileset B (includes 
  all entries in A).

  [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]

* Homogenize notion of PATHs and filesets.

  [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]

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

  [REJECTED as a primary goal - only two +1 votes]

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

  [REJECTED as part of Ant's core - veto by Conor MacNeill, no single +1]

[DISC] class loading
--------------------

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

  [REJECTED - only one +1 vote]

* 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

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister and Stefan
              Bodewig, ACCEPTED if optional]


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

  [ACCEPTED]

* Project inheritance

  What's this?

  [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]

* Target inheritance. ie The ability to include targets from other 
  project files overidining them as necessary (so cascading project
  files).

  [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]

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

  [REJECTED - vetoes by Conor MacNeill, Peter Donald, Simeon Fitch and
              Stefan Bodewig]

* Allow a target to depend on a target which is in another buildfile.  

  [ACCEPTED]

* Allow a target to reference properties defined in another buildfile.

  [REJECTED - only one +1 vote]

[DISC] documentation system
---------------------------

* generate docs by anakia/XSLT

  Corollary of "move to a system that allows docs to be generated"?

  [ACCEPTED - with no decision on which system to use]

[DISC] Task API
---------------

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

  [ACCEPTED]

* tasks should have access to its own XML representation.

  [REJECTED - vetoes by Christoph Wilhelms, Conor MacNeill and Simeon Fitch]

* Task level if and unless attributes.

  [REJECTED - no single +1 vote]

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

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
              and Stefan Bodewig]

* provide failonerror like functionality to all tasks. (Provide this as an aspect??
  much like logging aspect or classloader aspect).

  [ACCEPTED]

[DISC] logging
--------------

* allow build file writers to modify logging (verbosity for example)
  on a target by target or task by task basis.

  [ACCEPTED]

* Make loggers configurable via build.xml.

  [ACCEPTED]

[DISC] multithrading
--------------------

* Multithreaded execution of tasks within the same target.

  [ACCEPTED]

* Multithreaded execution of targets.

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister and Stefan Bodewig]

[DISC] procedural versus purely declarative
-------------------------------------------

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

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
              and Stefan Bodewig]

* targets should be like methods including a return value

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald,
              Simeon Fitch and Stefan Bodewig]

* build files should be purely declarative

  [REJECTED - veto by Stefan Bodewig]

[DISC] Properties
-----------------

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

  [ACCEPTED]

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

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
              and Stefan Bodewig]

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

  [ACCEPTED]

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

  [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
              and Stefan Bodewig]

* 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

  [ACCEPTED]

[DISC] core extensions
----------------------

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

  [REJECTED - only one +1 vote]

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

  [REJECTED - vetoes by Glenn McAllister, Peter Donald and Stefan Bodewig]

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

  [ACCEPTED]

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

  [ACCEPTED]

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

  [REJECTED - vetoes by Glenn McAllister and Stefan Bodewig]

* check for more than one condition in if/unless attributes.

  [REJECTED - vetoes by Glenn McAllister, Peter Donald and Stefan Bodewig]

* provide a way to define the order in which targets a given target
  depends upon get executed.

  [ACCEPTED]

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

  [ACCEPTED]

[DISC] organization
-------------------

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

  [REJECTED - vetoes by Conor MacNeill and Glenn McAllister]

[DISC] misc
-----------

* internationalization

  [ACCEPTED]

VI. entries that have been submitted too late
=============================================

* Integration of the depends task and javac tasks

  [REJECTED - only two +1 votes]

* recursive property resolution( ie resolving ${dist.${name}.dir} )

  [REJECTED - veto by Peter Donald]