bodewig 01/03/07 04:35:00
Modified: docs/ant2 requested-features.txt
Log:
Restructured requested-features.txt and added some comments. No new content.
Revision Changes Path
1.4 +98 -55 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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- requested-features.txt 2001/03/01 09:18:30 1.3
+++ requested-features.txt 2001/03/07 12:34:59 1.4
@@ -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 @@
* 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,15 +135,10 @@
</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
+ Installshield type app, Peter's cron-server and other task based
+ operations.
-* make separate build files easy (ala AntFarm) and importing different
- projects a breeze
-
* 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
@@ -94,31 +146,22 @@
* 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 ...
+ Corollary of "move to a system that allows docs to be generated"?
-* 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.
-
* 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.
|