From 730543998d9c95bf6d67eccef1b36735de2ac42d Mon Sep 17 00:00:00 2001 From: Stefan Bodewig Date: Wed, 7 Mar 2001 12:34:59 +0000 Subject: [PATCH] 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 | 153 ++++++++++++++++++++----------- 1 file changed, 98 insertions(+), 55 deletions(-) diff --git a/docs/ant2/requested-features.txt b/docs/ant2/requested-features.txt index 79115394f..9cb947e44 100644 --- a/docs/ant2/requested-features.txt +++ b/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 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 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 @@ -78,14 +135,9 @@ reception - * 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 unless something else has been - specified). Could be a CSS like language, could be a - 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.