diff --git a/docs/ant2/requested-features.txt b/docs/ant2/requested-features.txt index 17501eb74..493d41b04 100644 --- a/docs/ant2/requested-features.txt +++ b/docs/ant2/requested-features.txt @@ -124,8 +124,8 @@ decide between several possible options. 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. + or XSLT+ XML or Velocity+text 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. @@ -196,6 +196,31 @@ decide between several possible options. V. Things we probably don't agree on. ====================================================================== + * Allow mappers to be genericised so that particular features can be modified + during mapping. Something similar to + + + + + + + + + + + * Allow include/exclude tow work with multiple characteristerics of a file. + ie include into fileset if file is readable, modified after 29th of Feb, + has a name that matches patter "**/*.java" and the property "foo.present" + is set. Something similar to + + + + + + + * provide datatypes through property tag and remove need for separate free standing entities. ie @@ -208,6 +233,13 @@ V. Things we probably don't agree on. Installshield type app, Peter's cron-server and other task based operations. + * provide support for non-hardwired (ie loadable) low-level + components (mappers/itemset-filters/converters). Allow them to be + loaded in either global or a new classloader. + + * force resolution of classes on loading to identify classloader + issues early. (At least in global classloader). + * 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 @@ -215,11 +247,22 @@ V. Things we probably don't agree on. * provide support for CJAN - In what way? + Q: In what way? + A: Probably by supplying a set of tasks that download versioned + binaries and their associated dependencies, caching the downloads + in a known place and updating binaries when required. ("When required" + being indicated by a change in property values). * provide support for non-hardwired (ie loadable) converters. - What is a converter? Is this an implementation detail? + Q: What is a converter? Is this an implementation detail? + A: Not an implementation detail but a way to extend the engine + to convert more data types. Currently we have fixed set that is + expanded on occasion (ie includes primitive types + File). Instead + of spreading converting code through out tasks it can be centralized + into one component and used by engine. This becomes particularly + relevent if you build ant based testing systems and use ant in certain + web-related areas. * generate docs by anakia/XSLT @@ -230,7 +273,9 @@ V. Things we probably don't agree on. 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. + javadoc comments parsed by a custom doclet. Whatever the method it + should not impose any cost on runtime as it is only used a small + proportion of the time (design-time). * allow build file writers to modify logging (verbosity for example) on a target by target or task by task basis. @@ -250,13 +295,15 @@ V. Things we probably don't agree on. What's this? -* Target inheritance - - What's this? +* Target inheritance. ie The ability to include targets from other + project files overidining them as necessary (so cascading project + files). * Add an attribute to to feed back the environment (properties and taskdefs) from the child build to the parent. +* Ability to manage scopping of properties in general (ie target/project/workspace). + * 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. @@ -274,3 +321,6 @@ V. Things we probably don't agree on. * Let Ant ignore - but warn - if unknown XML elements or attributes occur in a build file. +* Allow ant to farm out attributes and elements that are NOT in the ant + namespace to other components. ie hand doc: elements to the Documentation + component or log: attributes to Log policy component etc