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. ====================================================================== * Add a new datatype filterset to group token-filters * make usage of particular filters/filtersets explicit in copy tasks * make facade tasks for things like javac (JikesImpl, ModernImpl etc) One candidate is rmic with implementations for Kaffee and Weblogic for example. * unify multiple similar tasks to use similar forms (ie all the javacc type tools) * Obfuscating task * Add an task that will find build files according to a fileset and invokes a common target in them. ? * Add a JavaApply task that executes a given class with files from a fileset as arguments - similar to . * Include some more sophisticated loggers with the Ant distribution - especially for sending emails. Make the existing one more flexible (stylesheet used by XmlLogger). Could be part of the same module task would be developed in? 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. * 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 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 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. * move to a system that allows docs to be generated - doc snippets should be included with the tasks they document. 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. * allow documentation to be stored in .tsk jars corollary of the two points above? * better scripting/notification support so the hooks are available to send notifications at certain times. Which hooks and where? * separate tasks into .tsk jars somehow. (Probably via function - ie java tasks, file tasks, ejb tasks). Decide on categories. * make separate build files easy (ala AntFarm) and importing different projects a breeze * 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). Three ideas so far: a CSS like language, a element, properties following a specific naming scheme. * support more control over the properties that are going to be passed to subprojects (modules) * Ask for a new CVS module for Ant tasks. We need to define rules for this to work - maybe the rules proposed for the commons project could give us a start. * It should be possible to modify details of the actual build (e.g. classpath, used compiler) without the need to change the build specification. Do build.compiler and build.sysclasspath cover everything or do we need to add more stuff like this? * Task to prompt for user input. Does affect core as we need a means to request input from the Frontend. * Add cvs login feature. Requires handling of user input. V. Things we probably don't agree on. ====================================================================== * provide datatypes through property tag and remove need for separate free standing entities. ie * make it possible to reuse taskengine for other things. ie 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 build process. It also helps CJAN to a lesser degree and would partially solve the JARs in CVS thing. * provide support for CJAN In what way? * provide support for non-hardwired (ie loadable) converters. What is a converter? Is this an implementation detail? * generate docs by anakia/XSLT 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. * allow build file writers to modify logging (verbosity for example) on a target by target or task by task basis. * Simple flow control (if-then-else, for) Either in core or - with the help of something like Thomas Christen's proposal as tasks. * Multithreaded execution of tasks within the same target. * Multithreaded execution of targets. * Project inheritance What's this? * Target inheritance What's this? * Add an attribute to to feed back the environment (properties and taskdefs) from the child build to the parent. * it should be possible to provide general /(template?)/ build specifications, and to declare for a concrete item that it should be built according to such a general specification. * a built-in mechanism to include build-file fragments - something that doesn't use SYSTEM entities at all and therefore is XSchema friendly, allows for property expansions ... * Make loggers configurable via build.xml.