| 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 |
| <property name="foo"> |
| <fileset dir="blah"> |
| <include name="*/**.java" /> |
| </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 |
| |
| * 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 <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. |
| |
| * 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. |
| |
