Added: ant/site/generated/ant2/requested-features.html
URL:
http://svn.apache.org/viewvc/ant/site/generated/ant2/requested-features.html?rev=439488&view=auto
==============================================================================
--- ant/site/generated/ant2/requested-features.html (added)
+++ ant/site/generated/ant2/requested-features.html Fri Sep 1 14:41:40 2006
@@ -0,0 +1,1090 @@
+<html>
+<body>
+
+<h2>
+<center>Requested Features for Ant2</center>
+</h2>
+
+<h4>
+I. Things that don't affect the core but are requests for new tasks or
+enhancements to existing tasks.
+</h4>
+
+"Accepted" for a task doesn't mean that
+task will be a core task (or even be supplied by a voter), just that having
+it (as an optional task) would be acceptable.
+<p>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Add a new datatype filterset to group token-filters.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make usage of particular filters/filtersets explicit in copy tasks.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make facade tasks for things like <code><javac></code>
+(JikesImpl, ModernImpl, etc.).
+(One candidate is <code><jar></code>, with implementations for
+a <code><fastjar></code>, for example.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Unify multiple similar tasks to use similar forms (eg., all the
+<code><javacc></code>-type
+tools).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Obfuscating task.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Better scripting/notification support so the hooks are available to
+send notifications at certain times.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Add an <code><ant></code> task that will find build files according
+to a fileset and invoke a common target in them. (<code><anton></code>?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Add a JavaApply task that executes a given class with files from a
+fileset as arguments (similar to <code><apply></code>).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+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 tasks
+would be developed in?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Better docs (eg., more examples, tutorials, beginner documents, reference
+sheets for tasks, printable version, etc.).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+RPM task.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Task for splitting files (head/tail/split-like functionality).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Task to create XMI from Java.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Socksified networking tasks, SSH tasks.
+(Peter Donald expressed some legal concerns that might need to be overcome,
+depending on the implementation.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+A reachable task that works much like <code><available></code>,
+for network URLs.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Task to extract classes from a jar-file that a given class depends on.
+(Based on <code><depend></code> or IBM's JAX, for example.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Unify <code><available></code> and <code><uptodate></code>
+into a more general
+<code><condition></code> task – support
+<code>AND</code>/<code>OR</code> of
+several tests here.
+(Will need more discussion because of vote by Peter Donald.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+JSP-compilation task. (Sounds like a candidate for a facade task.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+URL-spider task that checks links for missing content or server errors.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+<blockquote>
+<ul><li>
+Make the default logger's output clear, informative, and terse. (Rejectors
+think it already is.)
+</blockquote>
+</li></ul>
+
+<blockquote>
+<ul><li>
+Add an attribute to <code><property></code> to read in an entire file
+as the value of a property.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make PATH-handling consistent. Every task that has a PATH attribute
+must also accept references to PATHs.
+</li></ul>
+</blockquote>
+
+<br>
+<h4>
+II. Goals that need to be abstract until we get into design
+decisions.
+</h4>
+
+During the discussion it became obvious that some things from this list
+are goals for Ant and some should be guidelines for developers.
+Therefore, there are two flavors, "Accepted" and
+"Accepted As Guideline".
+<p>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Provide a clear mission statement for Ant.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Main goals<b>:</b> simplicity, understandability, extensibility.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Remove magic properties if at all humanly possible.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Remove as much dependency on native scripts as possible.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Clean object model (ie., Project/Target/Task).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Good event model to integrate well with IDE/GUI/etc.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Use a consistent naming scheme for attributes across all tasks.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Keep build-file syntax as compatible to Ant1 as possible
+(ie., don't break something just because we can).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Keep the interface for tasks as similar to that of Ant1 as
+possible (ie., don't break something just because we can).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Ant should be cancelable.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted As Guideline</b>
+</font>
+
+<blockquote>
+<ul><li>
+No commit of new features without documentation.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+No commit of new features without test-cases.
+</li></ul>
+</blockquote>
+
+<br>
+<h4>
+III. Things that are simple and easy to implement, where we expect the
+committers to agree.
+</h4>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Namespace support so different concerns can occupy different namespaces
+from Ant (thus, SAX2/JAXP1.1).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Java2
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Remove all deprecated methods, attributes, tasks.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow all datatypes to be defined anywhere (ie., as children of
+project as well as of target).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make properties fully dynamic (ie., allow their value to be reassigned).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Unify the namespace of all data types (ie., properties + filesets +
+patternsets + filtersets).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Add a user-defined message if a target will be skipped as a
+result of the specified <code>if/unless</code>.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow user datatypes to be defined via a <code><typedef></code>
+similar to <code><taskdef></code>.
+</li></ul>
+</blockquote>
+
+<br>
+<h4>
+IV. Things we probably agree on but need to discuss the details or
+decide between several possible options.
+</h4>
+
+"Accepted" means the goal/idea is fine, not that a decision on a
+particular implementation has been made.
+<p>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+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
+the object model (ie., GUITask extends Task) or to have Task as an
+interface (ie., GUITask implements Task). This way, the GUI tasks could
+be W3C DOM elements, have property vetoers/listeners, etc.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Support for numerous front-ends – from command-line over GUI to servlets.
+(Corollary of the above?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Fully interpreted at run-time. (This almost requires some form of
+abstraction/proxy that stands in place of tasks till it is
+interpreted. This can be hash-tables/simple DOM-like model/whatever.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide utility classes to aid in building tasks (ie., like
+<code><uptodate></code> functionality abstracted).
+(Need to become more specific here.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make ant-call a low-cost operation so it can do certain
+optional/template-like operations.
+(Corollary of "fully interpreted at run-time"?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow facilities to build projects from multiple sources (ie., CSS+XML,
+XSLT+XML, Velocity+text or database, from inside jars or normal
+<code>build.xml</code> files, etc.)
+(Allow the project tree to be built dynamically.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+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?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow tasks to be loaded from jars. (Use
+either an XML file in <code>TSK-INF/taskdefs.xml</code> or a
+manifest file.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow documentation to be stored in <code>.tsk</code> jars.
+(Corollary of the above two points?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Separate tasks into <code>.tsk</code> jars somehow.
+(Decide on categories.
+Probably via function – ie., java tasks, file tasks, EJB tasks, etc.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make having separate build-files easy (<i>à la</i> AntFarm) and importing
different
+projects a breeze.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide support for user-defined task configurations – (ie., give
+users the ability to specify a default value for attributes (eg., always
+use <code>debug="true"</code> in <code><javac></code> unless
+something else has been specified).
+(Three ideas so far<b>:</b> a CSS-like language,
+a <code><taskconfig></code> element, or
+properties following a specific naming scheme.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Support more control over the properties that are going to be passed
+to subprojects (modules).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Task to prompt for user input.
+(Does affect core, as we need a means to request input from the front-end.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Add CVS login feature.
+(Requires handling of user input.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Easier installation process. GUI, maybe webstart from the homepage.
+This includes asking the user whether he wants to use optional tasks
+and downloads the required libs, automatic upgrades and so on.
+
+Self-extracting jar installer<b>:</b>
+<br>
+ <code>java -jar jakarta-ant-1.3-bin.jar</code>
+<br>
+Prompts for destination directory, extracts archive, fixes all
+text files with <code><fixCRLF></code> task<b>;</b> on UNIX,
+makes scripts executable.
+Could also modify ant scripts with the location of <code>ANT_HOME</code>.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Logo for Ant.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Detach Ant from <code>System.err</code>/<code>.in</code>/<code>.out</code>.
+(Beware of problems with spawned processes.)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Build-files should be declarative in nature.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+<blockquote>
+<ul><li>
+It should be possible to modify details of the actual build (e.g. classpath,
+compiler used, etc.) without the need to change the build specification.
+(Do <code>build.compiler</code> and <code>build.sysclasspath</code>
+cover everything, or do we need to add more stuff like this?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Better sub-project handling
+(whatever that means in detail).
+</li></ul>
+</blockquote>
+
+<br>
+<h4>
+V. Things we probably don't agree on.
+</h4>
+<i><b>Datatypes</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Allow <code><include>/<exclude></code>
+to 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 the pattern <code>"**/*.java"</code> and
+the property <code>foo.present</code> is set. Something similar to<b>:</b>
+<pre>
+ <include>
+ <item-filter type="name" value="**/*.java"/>
+ <item-filter type="permission" value="r"/>
+ <!-- could optionally be directory or some other system specific
features -->
+ <item-filter type="type" value="file"/>
+ <item-filter type="modify-time"
+ operation="greater-than"
+ value="29th Feb 2003"/>
+ </include>
+</pre>
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide support for non-hardwired (ie., loadable) low-level
+components (mappers/itemset-filters/converters). Allow them to be
+loaded in either globally or via a new classloader.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide support for non-hardwired (ie., loadable) converters.
+<br>
+Q<b>:</b> What is a converter? Is this an implementation detail?
+<br>
+A<b>:</b> Not an implementation detail, but a way to extend the engine
+to convert more datatypes. Currently, we have a fixed set that is
+expanded on occasion (ie., includes primitive types + File). Instead
+of spreading converting code throughout the tasks, it can be centralized
+into one component and used by the engine. This becomes particularly
+relevent if you build Ant-based testing systems and use Ant in certain
+web-related areas.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Set-arithmetic for fileset/patternset/*set.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Inheritance of Ant properties/datatypes/context/etc. in project hierarchy.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Allow mappers to be genericized so that particular features can be modified
+during mapping. Something similar to<b>:</b>
+<pre>
+ <fileset ...>
+ <include name="*.sh"/>
+ <mapper type="unix-permissions">
+ <param name="user" value="ant"/>
+ <param name="group" value="ant"/>
+ <param name="mod" value="755"/>
+ </mapper>
+ </fileset>
+</pre>
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide datatypes through property tag and remove need for separate
+free-standing entities. That is<b>:</b><br>
+<pre>
+ <property name="foo">
+ <fileset dir="blah">
+ <include name="*/**.java" />
+ </fileset>
+ </property>
+</pre>
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make all datatypes interfaces to allow them to be customized in many
+ways.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Inheritance between Ant datatypes (ie., fileset A inherits from
+fileset B (includes all entries in A).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Homogenize notion of PATHs and filesets.
+</li></ul>
+</blockquote>
+
+<i><b>Ant's goals</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Provide support for CJAN.
+<br>
+Q: In what way?<br>
+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).
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b> (as a primary goal)
+</font>
+
+<blockquote>
+<ul><li>
+Make it possible to re-use the task engine for other things
+(ie., Installshield-type app, Peter's cron-server, and other task-based
+operations).
+</li></ul>
+</blockquote>
+
+<i><b>Class-loading</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Force resolution of classes on loading, to identify class-loader
+issues early (at least in global classloader).
+</li></ul>
+</blockquote>
+
+
+<blockquote>
+<ul><li>
+Ignore any classes contained in the damned ext dirs of a
+JVM – possibly by launching with something like<b>:</b>
+<br>
+ <code>jar -Djava.ext.dir=foo -jar ant.jar</code>
+<br>
+(Accepted if optional.)
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Workspace/sub-build issues</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+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.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow a target to depend on a target in another build-file.
+</li></ul>
+</blockquote>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Project inheritance. (What's this?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Target inheritance. That is, the ability to include targets from other
+project files, overriding them as necessary (so, cascading project
+files).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Add an attribute to <code><ant></code> to feed back the environment
+(properties and taskdefs) from the child build to the parent.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow a target to reference properties defined in another build-file.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Documentation system</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b> (with no decision on which system to use)
+</font>
+
+<blockquote>
+<ul><li>
+Generate docs by Anakia/XSLT.
+(Corollary of "move to a system that allows docs to be generated"?)
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Task API</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Tasks provide some way to identify their attributes from the outside.
+
+Possible solutions include a special method like <code>getProperties()</code>,
+an external describing file shipping with the task class or special
+Javadoc comments parsed by a custom doclet. Whatever the method, it
+should not impose any cost on run-time, as it is only used a small
+percentage of the time (design-time).
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide <code>"failonerror"</code>-like functionality to all tasks.
+(Provide this as an aspect?? Much like logging aspect or classloader aspect).
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Tasks should have access to its own XML representation.
+</blockquote>
+</li></ul>
+
+<blockquote>
+<ul><li>
+Task level if and unless attributes.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow tasks to find out, whether another task has completed successfully.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Logging</b></i>
+
+<blockquote>
+<ul><li>
+Allow build-file writers to modify logging (verbosity, for example)
+on a target-by-target or task-by-task basis.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make loggers configurable via build.xml.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Multi-threading</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Multi-threaded execution of tasks within the same target.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Multithreaded execution of targets.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Procedural versus purely declarative</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Simple flow-control (<code>if-then-else</code>, <code>for</code>)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Targets should be like methods, including a return value.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Build-files should be purely declarative.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Properties</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Ability to manage scoping of properties in general
+(ie., target/project/workspace).
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Templates</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+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.
+</ul></li>
+</blockquote>
+
+<p>
+<i><b>XML issues</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+A built-in mechanism to include build-file fragments – something
+that doesn't use <code>SYSTEM</code> entities at all and therefore is
+XSchema-friendly, allows for property expansions, etc.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Allow Ant to farm out attributes and elements that are <i>not</i>
+in the Ant namespace to other components (ie., hand <code>doc:</code> elements
+to the Documentation component or <code>log:</code> attributes to the Log
+policy component, etc.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Let Ant ignore – but warn – if unknown XML elements or attributes
+occur in a build-file.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Core extensions</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Allow sequence to be specified in <code>"depends"</code> attribute,
+or enhance <code><antcall></code> to work with current list of executed
+targets.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Provide a way to define the order in which targets that a given target
+depends upon get executed. (Same as above?)
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Support nesting tasks into other elements – not just as children of
+target – as proposed by Thomas Christen in
+<a href http://marc.theaimsgroup.com/?l=ant-dev&m=98130655812010&w=2>
+his mail message</a>.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Define task contexts that define various common aspects (logging,
+failure handling, etc.), and assign them to tasks.
+</li></ul>
+</blockquote>
+
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Allow named tasks to be defined by <code><script></code> elements.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Specify an OnFail task or target that runs in case of a build
+failure.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Make <code>if/unless</code> attributes check for the value of a property, not
+only its existance.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Check for more than one condition in <code>if/unless</code> attributes.
+</li></ul>
+</blockquote>
+
+<p>
+<i><b>Organization</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Separate CVSes and code hierarchies for<b>:</b>
+</li></ul>
+<ul type="circle">
+<li>task engine [org.apache.task.*]</li>
+<li>project engine (ie., model of targets/projects/workspaces) +
+support/utility classes [org.apache.ant.*]</li>
+<li>core tasks (ie., tasks supported by Ant contributors) [org.apache.???]</li>
+</ul>
+</blockquote>
+
+<p>
+<i><b>Miscellaneous</b></i>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Accepted</b>
+</font>
+
+<blockquote>
+<ul><li>
+Internationalization.
+</li></ul>
+</blockquote>
+
+<p>
+<h4>
+VI. Things that were submitted late
+</h4>
+
+<p>
+<font face="Arial, Helvetica, sans-serif" size="-1">
+ <b>Rejected</b>
+</font>
+
+<blockquote>
+<ul><li>
+Integration of the <code><depend></code> and <code><javac></code>
+tasks.
+</li></ul>
+</blockquote>
+
+<blockquote>
+<ul><li>
+Recursive property resolution (ie., resolving <code>${dist.${name}.dir}</code>)
+</li></ul>
+</blockquote>
+
+</body>
+</html>
+
Propchange: ant/site/generated/ant2/requested-features.html
------------------------------------------------------------------------------
svn:eol-style = native
Added: ant/site/generated/ant2/requested-features.txt
URL:
http://svn.apache.org/viewvc/ant/site/generated/ant2/requested-features.txt?rev=439488&view=auto
==============================================================================
--- ant/site/generated/ant2/requested-features.txt (added)
+++ ant/site/generated/ant2/requested-features.txt Fri Sep 1 14:41:40 2006
@@ -0,0 +1,766 @@
+Status:
+=======
+
+The committers have cast votes on all items (except those that came in
+too late) and the results are listed below - the next step will be a
+design phase.
+
+This list of items will be summarized into an Ant2 specification soon.
+
+I. Things that don't affect the core but are requests for new tasks or
+enhancements of existing tasks.
+======================================================================
+
+[ACCEPTED] for a task doesn't mean that task will be core tasks (or
+even be supplied by a voter), just that having them (as optional
+tasks) would be acceptable.
+
+* Add a new datatype filterset to group token-filters
+
+ [ACCEPTED]
+
+* make usage of particular filters/filtersets explicit in copy tasks
+
+ [ACCEPTED]
+
+* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
+
+ One candidate is jar with implementations for fastjar
+ for example.
+
+ [ACCEPTED]
+
+* unify multiple similar tasks to use similar forms (ie all the javacc
+ type tools)
+
+ [ACCEPTED]
+
+* Obfuscating task
+
+ [ACCEPTED]
+
+* Add an <ant> task that will find build files according to a fileset
+ and invokes a common target in them.
+
+ <anton>?
+
+ [will need more discussion because of votes by Peter Donald and
+ Stefan Bodewig]
+
+ [finally ACCEPTED]
+
+* Add a JavaApply task that executes a given class with files from a
+ fileset as arguments - similar to <apply>.
+
+ [will need more discussion because of votes by Peter Donald and
+ Stefan Bodewig]
+
+ [finally ACCEPTED]
+
+* 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 tasks would be developed in?
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [finally ACCEPTED]
+
+* make the default logger's output clear, informative, and terse.
+
+ Actually, this is a little bit abstract, but doesn't apply to the
+ core either.
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [REJECTED - vetoes by Conot MacNeill and Stefan Bodewig]
+
+* Better docs.
+
+ More examples. Tutorials, beginner documents, reference sheets for
+ tasks, printable version.
+
+ [ACCEPTED]
+
+* RPM task.
+
+ [ACCEPTED]
+
+* add an attribute to <property> to read in an entire file as the
+ value of a property.
+
+ [will need more discussion because of vote by Peter Donald]
+
+ [REJECTED - veto by Peter Donald]
+
+* Task for splitting files (head/tail/split like functionality).
+
+ [ACCEPTED]
+
+* Task to create XMI from Java.
+
+ [ACCEPTED]
+
+* socksified networking tasks, SSH tasks.
+
+ [Peter Donald expressed some legal concerns that might be overcome,
+ depending on the implementation]
+
+* a reachable task that works much like available for network URLs.
+
+ [ACCEPTED]
+
+* make PATH handling consistent. Every task that has a PATH attribute
+ must also accept references to PATHs.
+
+ [will need more discussion because of vote by Stefan Bodewig]
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister and Stefan Bodewig]
+
+* Task to extract classes from a JAR file that a given class depends
+ on.
+
+ Based on <depend> or IBM's JAX for example.
+
+ [ACCEPTED]
+
+* Unify <available> and <uptodate> into a more general <condition>
+ task, support AND/OR of several tests here.
+
+ [will need more discussion because of vote by Peter Donald]
+
+* jsp-compilation task
+
+ Sounds like a candidate for a facade task.
+
+ [ACCEPTED]
+
+* URL-spider task that checks links for missing content or server errors
+
+ [ACCEPTED]
+
+II. Abstract goals that need to be abstract until we get into design
+decisions.
+======================================================================
+
+During discussion it became obvious, that some things from this list
+are goals for Ant and some should be guidelines for developers,
+therefore there are two flavors, [ACCEPTED] and [ACCEPTED AS GUIDELINE].
+
+* Provide a clear mission statement for Ant.
+
+ [ACCEPTED]
+
+* Main goals: Simplicity, Understandability, Extensibility
+
+ [ACCEPTED]
+
+* remove magic properties if at all humanly possible
+
+ [ACCEPTED]
+
+* remove as much dependency on native scripts as possible.
+
+ [ACCEPTED]
+
+* clean object model (ie Project/Target/Task)
+
+ [ACCEPTED]
+
+* good event model to integrate well with IDE/GUI/whatever
+
+ [ACCEPTED]
+
+* use a consistent naming scheme for attributes across all tasks
+
+ [ACCEPTED]
+
+* keep build file syntax as compatible to Ant1 as possible -
+ i.e. don't break something just because we can.
+
+ [ACCEPTED]
+
+* keep the interface for Tasks as similar to the one of Ant1 as
+ possible - i.e. don't break something just because we can.
+
+ [ACCEPTED]
+
+* Ant should be cancelable
+
+ [ACCEPTED]
+
+* no commit of new features without documentation
+
+ [ACCEPTED AS GUIDELINE]
+
+* no commit of new features without testcases
+
+ [ACCEPTED AS GUIDELINE]
+
+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)
+
+ [ACCEPTED]
+
+* Java2
+
+ [ACCEPTED]
+
+* remove all deprecated methods, attributes, tasks
+
+ [ACCEPTED]
+
+* allow all datatypes to be defined anywhere - i.e. as children of
+ project as well as of target.
+
+ [ACCEPTED]
+
+* make properties fully dynamic, i.e. allow their value to be reassigned
+
+ [will need more discussion because of vote by Glenn McAllister and
+ Conor MacNeill]
+
+ [finally ACCEPTED]
+
+* unify the namespace of all data types (ie properties + filesets +
+ patternset + filtersets).
+
+ [ACCEPTED]
+
+* add a user defined message if a target will be skipped because the
+ if/unless attribute says so.
+
+ [ACCEPTED]
+
+* allow user-datatypes to be defined via a <typedef> similar to <taskdef>.
+
+ [ACCEPTED]
+
+IV. Things we probably agree upon but need to discuss the details or
+decide between several possible options.
+======================================================================
+
+[ACCEPTED] means, the goal/idea is fine, not that a decission on a
+particular implementation has been made.
+
+* 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.
+
+ [ACCEPTED]
+
+* support for numerous frontends - from command line over GUI to servlets
+
+ corollary of the above?
+
+ [ACCEPTED]
+
+* 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
+
+ [ACCEPTED]
+
+* provide utility classes to aid in building tasks. ie like up-to-date
+ functionality abstracted
+
+ Need to become more specific here.
+
+ [ACCEPTED]
+
+* make ant-call a low cost operations so it can certain
+ optional/template-like operations
+
+ corollary of "fully interpreted at runtime"?
+
+ [ACCEPTED]
+
+* allow facilities to build projects from multiple sources. ie CSS+xml
+ or XSLT+ XML or Velocity+text or database or from inside jars or normal
+ build.xmls etc.
+
+ allow the project tree to be built dynamically.
+
+ [ACCEPTED]
+
+* 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?
+
+ [ACCEPTED]
+
+* allow tasks to be loaded from jars. tasks should be indicated by
+ either xml file in TSK-INF/taskdefs.xml or manifest file.
+
+ [ACCEPTED]
+
+* allow documentation to be stored in .tsk jars
+
+ corollary of the two points above?
+
+ [ACCEPTED]
+
+* better scripting/notification support so the hooks are available to
+ send notifications at certain times.
+
+ Which hooks and where?
+
+ [will need more discussion because of vote by Peter Donald and
+ Simeon Fitch]
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Simeon Fitch]
+
+* separate tasks into .tsk jars somehow. (Probably via function - ie
+ java tasks, file tasks, ejb tasks).
+
+ Decide on categories.
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [finally ACCEPTED]
+
+* make separate build files easy (ala AntFarm) and importing different
+ projects a breeze
+
+ [ACCEPTED]
+
+* 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).
+
+ Three ideas so far: a CSS like language, a <taskconfig> element,
+ properties following a specific naming scheme.
+
+ [ACCEPTED]
+
+* support more control over the properties that are going to be passed
+ to subprojects (modules)
+
+ [ACCEPTED]
+
+* 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.
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [REJECTED - vetoes by Conor MacNeill and Glenn McAllister]
+
+* 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?
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [REJECTED - veto by Conor MacNeill]
+
+* Task to prompt for user input.
+
+ Does affect core as we need a means to request input from the Frontend.
+
+ [ACCEPTED]
+
+* Add cvs login feature.
+
+ Requires handling of user input.
+
+ [ACCEPTED]
+
+* Easier installation process. GUI - maybe webstart from the homepage.
+
+ This includes asking the user whether he wants to use optional tasks
+ and downloads the required libs. Automatic upgrades and so on.
+
+ Self-extracting jar installer: java -jar jakarta-ant-1.3-bin.jar.
+ Prompts for destination directory, extracts archive, fixes all
+ text files with fixCRLF task; on UNIX, makes scripts executable.
+ Could also modify ant scripts with the location of ANT_HOME.
+
+ [ACCEPTED]
+
+* Logo for Ant.
+
+ [ACCEPTED]
+
+* detach Ant from System.err/.in/.out.
+
+ Beware of problems with spawned processes.
+
+ [ACCEPTED]
+
+* better subproject handling
+
+ Whatever that means in detail.
+
+ [will need more discussion because of vote by Conor MacNeill]
+
+ [REJECTED - vetoes by Conor MacNeill and Stefan Bodewig]
+
+* build files should be declarative in nature
+
+ [ACCEPTED]
+
+V. Things we probably don't agree on.
+======================================================================
+
+[DISC] Datatypes
+----------------
+
+ * Allow mappers to be genericised so that particular features can be modified
+ during mapping. Something similar to
+
+ <fileset ...>
+ <include name="*.sh"/>
+ <mapper type="unix-permissions">
+ <param name="user" value="ant"/>
+ <param name="group" value="ant"/>
+ <param name="mod" value="755"/>
+ </mapper>
+ </fileset>
+
+ [REJECTED - vetoes by Stefan Bodewig and Conor MacNeill, not enough
+ positive votes anyway.]
+
+ * 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
+
+ <include>
+ <item-filter type="name" value="**/*.java"/>
+ <item-filter type="permission" value="r"/>
+
+ <!-- could optionally be directory/or some other system specific features
-->
+ <item-filter type="type" value="file"/>
+ <item-filter type="modify-time"
+ operation="greater-than"
+ value="29th Feb 2003"/>
+ </include>
+
+ [ACCEPTED]
+
+* provide datatypes through property tag and remove need for separate free
+ standing entities. ie
+ <property name="foo">
+ <fileset dir="blah">
+ <include name="*/**.java" />
+ </fileset>
+ </property>
+
+ [REJECTED - only one +1 vote]
+
+* 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.
+
+ [ACCEPTED]
+
+* provide support for non-hardwired (ie loadable) converters.
+
+ 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.
+
+ [ACCEPTED]
+
+* Make all datatypes interfaces to allow them to be customized in many
+ ways.
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]
+
+* Set arithmetic for fileset/patternset/*set
+
+ [ACCEPTED]
+
+* inheritance of ant properties/datatypes/context etc in project hierarchy
+
+ [ACCEPTED]
+
+* inheritance of between ant datatypes. ie fileset A inherits from fileset B
(includes
+ all entries in A).
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]
+
+* Homogenize notion of PATHs and filesets.
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]
+
+[DISC] Ant's goals
+------------------
+
+* make it possible to reuse taskengine for other things. ie
+ Installshield type app, Peter's cron-server and other task based
+ operations.
+
+ [REJECTED as a primary goal - only two +1 votes]
+
+* provide support for CJAN
+
+ 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).
+
+ [REJECTED as part of Ant's core - veto by Conor MacNeill, no single +1]
+
+[DISC] class loading
+--------------------
+
+ * force resolution of classes on loading to identify classloader
+ issues early. (At least in global classloader).
+
+ [REJECTED - only one +1 vote]
+
+* Ignore any classes contained in the damned ext dirs of a JVM - possibly by
launching
+ with something like jar -Djava.ext.dir=foo -jar ant.jar
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister and Stefan
+ Bodewig, ACCEPTED if optional]
+
+
+[DISC] workspace/subbuild issues
+--------------------------------
+
+* 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.
+
+ [ACCEPTED]
+
+* Project inheritance
+
+ What's this?
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]
+
+* Target inheritance. ie The ability to include targets from other
+ project files overidining them as necessary (so cascading project
+ files).
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald and Stefan Bodewig]
+
+* Add an attribute to <ant> to feed back the environment (properties and
+ taskdefs) from the child build to the parent.
+
+ [REJECTED - vetoes by Conor MacNeill, Peter Donald, Simeon Fitch and
+ Stefan Bodewig]
+
+* Allow a target to depend on a target which is in another buildfile.
+
+ [ACCEPTED]
+
+* Allow a target to reference properties defined in another buildfile.
+
+ [REJECTED - only one +1 vote]
+
+[DISC] documentation system
+---------------------------
+
+* generate docs by anakia/XSLT
+
+ Corollary of "move to a system that allows docs to be generated"?
+
+ [ACCEPTED - with no decision on which system to use]
+
+[DISC] Task API
+---------------
+
+* 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. Whatever the method it
+ should not impose any cost on runtime as it is only used a small
+ proportion of the time (design-time).
+
+ [ACCEPTED]
+
+* tasks should have access to its own XML representation.
+
+ [REJECTED - vetoes by Christoph Wilhelms, Conor MacNeill and Simeon Fitch]
+
+* Task level if and unless attributes.
+
+ [REJECTED - no single +1 vote]
+
+* Allow tasks to find out, whether another task has completed successfully.
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
+ and Stefan Bodewig]
+
+* provide failonerror like functionality to all tasks. (Provide this as an
aspect??
+ much like logging aspect or classloader aspect).
+
+ [ACCEPTED]
+
+[DISC] logging
+--------------
+
+* allow build file writers to modify logging (verbosity for example)
+ on a target by target or task by task basis.
+
+ [ACCEPTED]
+
+* Make loggers configurable via build.xml.
+
+ [ACCEPTED]
+
+[DISC] multithrading
+--------------------
+
+* Multithreaded execution of tasks within the same target.
+
+ [ACCEPTED]
+
+* Multithreaded execution of targets.
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister and Stefan Bodewig]
+
+[DISC] procedural versus purely declarative
+-------------------------------------------
+
+* Simple flow control (if-then-else, for)
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
+ and Stefan Bodewig]
+
+* targets should be like methods including a return value
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald,
+ Simeon Fitch and Stefan Bodewig]
+
+* build files should be purely declarative
+
+ [REJECTED - veto by Stefan Bodewig]
+
+[DISC] Properties
+-----------------
+
+* Ability to manage scopping of properties in general (ie
target/project/workspace).
+
+ [ACCEPTED]
+
+[DISC] Templates
+----------------
+
+* 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.
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
+ and Stefan Bodewig]
+
+[DISC] XML issues
+-----------------
+
+* 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 ...
+
+ [ACCEPTED]
+
+* Let Ant ignore - but warn - if unknown XML elements or attributes
+ occur in a build file.
+
+ [REJECTED - vetoes by Conor MacNeill, Glenn McAllister, Peter Donald
+ and Stefan Bodewig]
+
+* 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
+
+ [ACCEPTED]
+
+[DISC] core extensions
+----------------------
+
+* Allow named tasks to be defined by <script> elements.
+
+ [REJECTED - only one +1 vote]
+
+* specify an onfail task or target that runs in case of a build
+ failure.
+
+ [REJECTED - vetoes by Glenn McAllister, Peter Donald and Stefan Bodewig]
+
+* allow sequence to be specified in depends attribute or enhance
+ antcall to work with current list of executed targets
+
+ [ACCEPTED]
+
+* Support nesting tasks into other elements - not just as children of
+ target - as proposed by Thomas Christen in
+ <http://marc.theaimsgroup.com/?l=ant-dev&m=98130655812010&w=2>.
+
+ [ACCEPTED]
+
+* Make if/unless attributes to check for the value of a property, not
+ only its existance.
+
+ [REJECTED - vetoes by Glenn McAllister and Stefan Bodewig]
+
+* check for more than one condition in if/unless attributes.
+
+ [REJECTED - vetoes by Glenn McAllister, Peter Donald and Stefan Bodewig]
+
+* provide a way to define the order in which targets a given target
+ depends upon get executed.
+
+ [ACCEPTED]
+
+* define task contexts that define various common aspects (logging,
+ failure handling ...) and assign them to tasks.
+
+ [ACCEPTED]
+
+[DISC] organization
+-------------------
+
+* separate CVSes and code hierarchies for
+ - task engine [ org.apache.task.* ]
+ - project engine (ie model of targets/projects/workspaces) + support/utility
classes
+ [ org.apache.ant.* ]
+ - core tasks (ie tasks supported by ant contributors) [ org.apache.??? ]
+
+ [REJECTED - vetoes by Conor MacNeill and Glenn McAllister]
+
+[DISC] misc
+-----------
+
+* internationalization
+
+ [ACCEPTED]
+
+VI. entries that have been submitted too late
+=============================================
+
+* Integration of the depends task and javac tasks
+
+ [REJECTED - only two +1 votes]
+
+* recursive property resolution( ie resolving ${dist.${name}.dir} )
+
+ [REJECTED - veto by Peter Donald]
Propchange: ant/site/generated/ant2/requested-features.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
