From 62d641e0123356ed4440e6a6b8211029a8190ae9 Mon Sep 17 00:00:00 2001 From: Stefan Bodewig Date: Fri, 19 Jan 2001 09:00:22 +0000 Subject: [PATCH] Brainstormed list of requested features for Ant2. This is far from being a functional-requirements document, just a start. Most of it taken from an email by Peter Donald and my response to it . Added some additional stuff to the end of the controversial section. git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@268479 13f79535-47bb-0310-9956-ffa450edef68 --- docs/ant2/requested-features.txt | 116 +++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 docs/ant2/requested-features.txt diff --git a/docs/ant2/requested-features.txt b/docs/ant2/requested-features.txt new file mode 100644 index 000000000..e6518e423 --- /dev/null +++ b/docs/ant2/requested-features.txt @@ -0,0 +1,116 @@ +Brainstormed and unordered list of requested features of Ant2: + +* namespace support so different concerns can occupy different namespaces + from ant (thus SAX2/JAXP1.1) + +* Java2 + +* 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. + +* Fully interpreted at runtime. This almost requires some form of + abstraction/proxy that stands in place of tasks till it is + interpreted. This can be hashtables/simple dom-like model/whatever + +* provide utility classes to aid in building tasks. ie like up-to-date + functionality abstracted + +* make ant-call a low cost operations so it can certain + optional/template-like operations + +* 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 + +* 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) + +* good event model to integrate well with IDE/GUI/whatever + +* better scripting/notification support so the hooks are available to + send notifications at certain times. + +* allow all datatypes to be defined anywhere + +* 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 + java tasks, file tasks, ejb tasks). + +* unify multiple similar tasks to use similar forms (ie all the javacc + type tools) + +* support for numerous frontends - from command line over GUI to servlets + +* make properties fully dynamic, i.e. allow their value to be reassigned + +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 + +* unify the namespace of all data types (ie properties + filesets + + patternset + filtersets). + +* provide datatypes through property tag and remove need for seperate free + standing entities. ie + + + + + + + +* 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 + +* 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 + +* provide support for non-hardwired (ie loadable) converters. + +* provide support for non-hardwired (ie loadable) datatypes. + +* 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. \ No newline at end of file