Restructured requested-features.txt and added some comments. No new content.

git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@268760 13f79535-47bb-0310-9956-ffa450edef68

docs/ant2/requested-features.txt

@@ -1,16 +1,74 @@
-Brainstormed and unordered list of requested features of Ant2:
+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.
+======================================================================
+
+* make usage of particular filters/filtersets explicit in copy tasks
+
+* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
+
+* unify multiple similar tasks to use similar forms (ie all the javacc
+  type tools)
+
+II. Abstract goals that need to be abstract until we get into design
+decisions.
+======================================================================
+
+* 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.
+
+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).
+
+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.
+  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
@@ -19,58 +77,57 @@ Brainstormed and unordered list of requested features of Ant2:
 * 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 database or from inside jars or normal build.xmls
   etc.
 
-* remove magic properties if at all humanly possible
-
-* make all tasks consistent and remove all deprecated methods
-
 * move to a system that allows docs to be generated - doc snippets
   should be included with the tasks they document.
 
-* allow documentation to be stored in .tsk jars
+  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.
 
-* remove as much dependency on native scripts as possible.
-
-* clean object model (ie Project/Target/Task)
+* allow documentation to be stored in .tsk jars
 
-* good event model to integrate well with IDE/GUI/whatever
+  corollary of the two points above?
 
 * better scripting/notification support so the hooks are available to
   send notifications at certain times.
 
-* allow all datatypes to be defined anywhere
+  Which hooks and where?
 
-* make usage of particular filters/filtersets explicit in copy tasks
-
-* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
-
-* seperate tasks into .tsk jars somehow. (Probably via function - ie
+* separate tasks into .tsk jars somehow. (Probably via function - ie
   java tasks, file tasks, ejb tasks).
 
-* unify multiple similar tasks to use similar forms (ie all the javacc
-  type tools)
+  Decide on categories.
 
-* support for numerous frontends - from command line over GUI to servlets
+* make separate build files easy (ala AntFarm) and importing different
+  projects a breeze
 
-* make properties fully dynamic, i.e. allow their value to be reassigned
+* 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). 
 
-Now there is a bunch of "controvertial" points. By controvertial I mean not
-everyone agrees or else there has not been enough comments to to judge
-reception
+  Three ideas so far: a CSS like language, a <taskconfig> element,
+  properties following a specific naming scheme.
 
-* unify the namespace of all data types (ie properties + filesets +
-  patternset + filtersets).
+* support more control over the properties that are going to be passed
+  to subprojects (modules)
+
+V. Things we probably don't agree on. 
+======================================================================
 
-* provide datatypes through property tag and remove need for seperate free
+* provide datatypes through property tag and remove need for separate free
   standing entities. ie
   <property name="foo">
     <fileset dir="blah">
@@ -78,14 +135,9 @@ reception
     </fileset>
   </property>
 
-
 * make it possible to reuse taskengine for other things. ie
-  Installshield type app, my cron-server and other task based
-  operations. Currently no committer other than me has expressed
-  positive or negative thoughts about this
-
-* make separate build files easy (ala AntFarm) and importing different
-  projects a breeze
+  Installshield type app, Peter's cron-server and other task based
+  operations. 
 
 * 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
@@ -94,31 +146,22 @@ reception
 
 * provide support for CJAN
 
+  In what way?
+
 * provide support for non-hardwired (ie loadable) converters.
 
-* provide support for non-hardwired (ie loadable) datatypes.
+  What is a converter? Is this an implementation detail?
 
 * generate docs by anakia/XSLT
 
-* 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). Could be a CSS like language, could be a <taskconfig>
-  element ...
-
-* support more control over the properties that are going to be passed
-  to subprojects (modules)
-
-* 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.
+  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.
+  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.
 
 * allow build file writers to modify logging (verbosity for example)
   on a target by target or task by task basis.