| <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> |
| <bl><li> |
| Add a new datatype filterset to group token-filters. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make usage of particular filters/filtersets explicit in copy tasks. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Unify multiple similar tasks to use similar forms (eg., all the |
| <code><javacc></code>-type |
| tools). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Obfuscating task. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Better scripting/notification support so the hooks are available to |
| send notifications at certain times. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Add a JavaApply task that executes a given class with files from a |
| fileset as arguments (similar to <code><apply></code>). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Better docs (eg., more examples, tutorials, beginner documents, reference |
| sheets for tasks, printable version, etc.). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| RPM task. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Task for splitting files (head/tail/split-like functionality). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Task to create XMI from Java. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Socksified networking tasks, SSH tasks. |
| (Peter Donald expressed some legal concerns that might need to be overcome, |
| depending on the implementation.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| A reachable task that works much like <code><available></code>, |
| for network URLs. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| JSP-compilation task. (Sounds like a candidate for a facade task.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| URL-spider task that checks links for missing content or server errors. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| <blockquote> |
| <bl><li> |
| Make the default logger's output clear, informative, and terse. (Rejectors |
| think it already is.) |
| </blockquote> |
| </li></bl> |
| |
| <blockquote> |
| <bl><li> |
| Add an attribute to <code><property></code> to read in an entire file |
| as the value of a property. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make PATH-handling consistent. Every task that has a PATH attribute |
| must also accept references to PATHs. |
| </li></bl> |
| </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> |
| <bl><li> |
| Provide a clear mission statement for Ant. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Main goals<b>:</b> simplicity, understandability, extensibility. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Remove magic properties if at all humanly possible. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Remove as much dependency on native scripts as possible. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Clean object model (ie., Project/Target/Task). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Good event model to integrate well with IDE/GUI/etc. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Use a consistent naming scheme for attributes across all tasks. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Keep build-file syntax as compatible to Ant1 as possible |
| (ie., don't break something just because we can). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Keep the interface for tasks as similar to that of Ant1 as |
| possible (ie., don't break something just because we can). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Ant should be cancelable. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted As Guideline</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| No commit of new features without documentation. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| No commit of new features without test-cases. |
| </li></bl> |
| </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> |
| <bl><li> |
| Namespace support so different concerns can occupy different namespaces |
| from Ant (thus, SAX2/JAXP1.1). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Java2 |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Remove all deprecated methods, attributes, tasks. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow all datatypes to be defined anywhere (ie., as children of |
| project as well as of target). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make properties fully dynamic (ie., allow their value to be reassigned). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Unify the namespace of all data types (ie., properties + filesets + |
| patternsets + filtersets). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Add a user-defined message if a target will be skipped as a |
| result of the specified <code>if/unless</code>. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow user datatypes to be defined via a <code><typedef></code> |
| similar to <code><taskdef></code>. |
| </li></bl> |
| </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> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Support for numerous front-ends – from command-line over GUI to servlets. |
| (Corollary of the above?) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Provide utility classes to aid in building tasks (ie., like |
| <code><uptodate></code> functionality abstracted). |
| (Need to become more specific here.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow documentation to be stored in <code>.tsk</code> jars. |
| (Corollary of the above two points?) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Separate tasks into <code>.tsk</code> jars somehow. |
| (Decide on categories. |
| Probably via function – ie., java tasks, file tasks, EJB tasks, etc.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make having separate build-files easy (<i>à la</i> AntFarm) and importing different |
| projects a breeze. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Support more control over the properties that are going to be passed |
| to subprojects (modules). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Task to prompt for user input. |
| (Does affect core, as we need a means to request input from the front-end.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Add CVS login feature. |
| (Requires handling of user input.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Logo for Ant. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Detach Ant from <code>System.err</code>/<code>.in</code>/<code>.out</code>. |
| (Beware of problems with spawned processes.) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Build-files should be declarative in nature. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Better sub-project handling |
| (whatever that means in detail). |
| </li></bl> |
| </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> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Set-arithmetic for fileset/patternset/*set. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Inheritance of Ant properties/datatypes/context/etc. in project hierarchy. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make all datatypes interfaces to allow them to be customized in many |
| ways. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Inheritance between Ant datatypes (ie., fileset A inherits from |
| fileset B (includes all entries in A). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Homogenize notion of PATHs and filesets. |
| </li></bl> |
| </blockquote> |
| |
| <i><b>Ant's goals</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> (as a primary goal) |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <i><b>Class-loading</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Force resolution of classes on loading, to identify class-loader |
| issues early (at least in global classloader). |
| </li></bl> |
| </blockquote> |
| |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Workspace/sub-build issues</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow a target to depend on a target in another build-file. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Project inheritance. (What's this?) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Target inheritance. That is, the ability to include targets from other |
| project files, overriding them as necessary (so, cascading project |
| files). |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Add an attribute to <code><ant></code> to feed back the environment |
| (properties and taskdefs) from the child build to the parent. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow a target to reference properties defined in another build-file. |
| </li></bl> |
| </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> |
| <bl><li> |
| Generate docs by Anakia/XSLT. |
| (Corollary of "move to a system that allows docs to be generated"?) |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Task API</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Provide <code>"failonerror"</code>-like functionality to all tasks. |
| (Provide this as an aspect?? Much like logging aspect or classloader aspect). |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Tasks should have access to its own XML representation. |
| </blockquote> |
| </li></bl> |
| |
| <blockquote> |
| <bl><li> |
| Task level if and unless attributes. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Allow tasks to find out, whether another task has completed successfully. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Logging</b></i> |
| |
| <blockquote> |
| <bl><li> |
| Allow build-file writers to modify logging (verbosity, for example) |
| on a target-by-target or task-by-task basis. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make loggers configurable via build.xml. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Multi-threading</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Multi-threaded execution of tasks within the same target. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Multithreaded execution of targets. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Procedural versus purely declarative</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Simple flow-control (<code>if-then-else</code>, <code>for</code>) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Targets should be like methods, including a return value. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Build-files should be purely declarative. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Properties</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Ability to manage scoping of properties in general |
| (ie., target/project/workspace). |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Templates</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><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. |
| </bl></li> |
| </blockquote> |
| |
| <p> |
| <i><b>XML issues</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Let Ant ignore – but warn – if unknown XML elements or attributes |
| occur in a build-file. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Core extensions</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Accepted</b> |
| </font> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Provide a way to define the order in which targets that a given target |
| depends upon get executed. (Same as above?) |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><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></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Define task contexts that define various common aspects (logging, |
| failure handling, etc.), and assign them to tasks. |
| </li></bl> |
| </blockquote> |
| |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Allow named tasks to be defined by <code><script></code> elements. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Specify an OnFail task or target that runs in case of a build |
| failure. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Make <code>if/unless</code> attributes check for the value of a property, not |
| only its existance. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Check for more than one condition in <code>if/unless</code> attributes. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <i><b>Organization</b></i> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Separate CVSes and code hierarchies for<b>:</b> |
| </li></bl> |
| <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> |
| <bl><li> |
| Internationalization. |
| </li></bl> |
| </blockquote> |
| |
| <p> |
| <h4> |
| VI. Things that were submitted late |
| </h4> |
| |
| <p> |
| <font face="Arial, Helvetica, sans-serif" size="-1"> |
| <b>Rejected</b> |
| </font> |
| |
| <blockquote> |
| <bl><li> |
| Integration of the <code><depend></code> and <code><javac></code> |
| tasks. |
| </li></bl> |
| </blockquote> |
| |
| <blockquote> |
| <bl><li> |
| Recursive property resolution (ie., resolving <code>${dist.${name}.dir}</code>) |
| </li></bl> |
| </blockquote> |
| |
| </body> |
| </html> |
| |