| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Language" content="en-us"> |
| <title>Ant2 feature list</title> |
| |
| <style type="text/css"> |
| .comment { |
| COLOR: #900000; |
| BACKGROUND: #ffa; |
| } |
| </style> |
| |
| </head> |
| |
| <body bgcolor="#FFFFFF"> |
| |
| <p class="comment">If something looks like this, this is either a |
| request for input or a "REVISIT" marker or similar.</p> |
| |
| <h1>Ant2 Goals</h1> |
| |
| <p>Even though Ant2 is expected to be incompatible with the |
| current Ant1 series, it still has the same goals. Ant is a Java |
| based build tool and this remains the main focus of it. The |
| original goals of simplicity, understandability and extensibility |
| still stand and Ant2 will try to achieve them even better than |
| Ant1 does.</p> |
| |
| <h2>Simplicity and Understandability</h2> |
| |
| <p>These two goals are closely related. Ant build files shall be |
| easy to read and understand - at the same time it should be easy |
| to write a custom Ant task and to use the utility classes that |
| Ant2 provides.</p> |
| |
| <p>Ant2 shall be more consistent than Ant1 is - this means:</p> |
| |
| <ul> |
| |
| <li>core tasks will use the same attribute names for common |
| functionality</li> |
| |
| <li>similar tasks will be unified to use similar forms.</li> |
| |
| <li>different implementations for the same functionality will be |
| hidden behind facade tasks.</li> |
| |
| <li>properties and data types will be unified so that they share |
| the same namespace and inheritance rules. <i |
| class="comment">Need to talk about how ${} expansion works for |
| filesets and so on.</i></li> |
| |
| </ul> |
| |
| <p>Furthermore some things will have to become more explicit:</p> |
| |
| <ul> |
| |
| <li>remove all magic properties</li> |
| |
| <li>make build file writers explicitly state which |
| filters/filtersets a copy task will use</li> |
| |
| <li>add scoping rules for properties so that not all of them |
| will be inherited by sub-builds, only those that have been |
| specified explicitly. <i class="comment">Fill in details once |
| they've been sorted out.</i></li> |
| |
| </ul> |
| |
| <p>The front-ends for Ant2 shall be smart enough to automatically |
| detect the required libraries (like <code>tools.jar</code>), the |
| use of native scripts shall be kept to a minimum.</p> |
| |
| <p>Build file writers can attach a message to targets that will be |
| presented to the user if that target is going to be skipped (based |
| on the if/unless attribute of the target).</p> |
| |
| <p>Even though Ant installation already is quite simple in Ant1 |
| (extract the archive and set two environment variables), |
| alternative ways to install Ant like using |
| <a href="http://java.sun.com/products/javawebstart/">Webstart</a> or |
| a "self-extracting" JAR file will be explored.</p> |
| |
| <h2>Extensibility</h2> |
| |
| <p>Ant2 like Ant1 uses build files written in XML as its main |
| input, but it will not be restricted to it. The core of Ant2 will |
| work on an object model of Project/Target/Task that is independent |
| of any external representation.</p> |
| |
| <p>As an extension of the current <code><taskdef></code> |
| concept, tasks can be bundled into task libraries (together with |
| data types and other utility classes). These task libraries are |
| special JAR archives that somehow describe the contained tasks to |
| Ant. Ant will automatically know all tasks contained in task |
| libraries that have been placed into a special directory - in |
| addition task libraries can be referenced and used in a build file |
| explicitly. <i class="comment">Fill in details once they've been |
| sorted out.</i></p> |
| |
| <p>It has become apparent, that several "aspects" of |
| tasks are so common that task writers find themselves duplicating |
| code all over again - things like classpath handling or "do |
| we stop the build if this task fails?" functionality for |
| example. Ant2 will provide a way to let the user attach an |
| "aspect handler" to a project - all attributes that live |
| in a certain namespace are going to be passed to this handler. <i |
| class="comment">Need to talk about TaskContext here.</i></p> |
| |
| <p>Ant2 will farm out common functionality from tasks into utility |
| classes so that task writers can benefit from a tested and stable |
| framework - they shouldn't need to deal with existing tasks |
| directly (like some tasks "abuse" the |
| <code><touch></code> task in Ant1).</p> |
| |
| <p>Ant2 will provide a way to define tasks that itself can have |
| tasks as child elements without knowing all defined tasks at |
| compile time. Discussions on ant-dev usually talk about |
| "container tasks" in this context.</p> |
| |
| <p>The only way to "include" common XML snippets so far |
| has been the usage of external SYSTEM entities, a mechanism that |
| is tied to DTDs and doesn't mix well with alternative |
| approaches like XML Schema. Ant2 will provide a built-in include |
| mechanism.</p> |
| |
| <h1>New/Modified Features</h1> |
| |
| <p>Ant2 will run the build process fully dynamically, which means |
| that task won't be instantiated before they are actually being run |
| and <code>${}</code> expansion will see the very latest value of a |
| property. It will be possible to reassign values of properties via |
| a built-in task.</p> |
| |
| <h2>Compatibility with Ant1</h2> |
| |
| <p>Ant2 is going to break Ant1 in several ways:</p> |
| |
| <ul> |
| |
| <li>Tasks written for Ant1 won't work in Ant2 as the API of |
| Ant's core and the names of utility classes are going to |
| change. There will probably be adaptors and utility classes to |
| ease the transition for task writers.</li> |
| |
| <li>Build files written for Ant1 will probably not be valid in |
| Ant2 or at least not yield the same results. It is expected that |
| Ant2 will come with a tool to translate Ant1 build files into |
| equivalent Ant2 versions</li> |
| |
| <li>magic properties like <code>build.compiler</code> may |
| disappear and be replaced by a different customization |
| concept.</li> |
| |
| <li>Ant2 is going to require a JDK version 1.2 or above and a |
| JAXP compliant parser version 1.1 or above.</li> |
| |
| <li>If you specify more than one target in another target's |
| depends attribute, Ant1 will execute these targets from left to |
| right (as long as the dependency tree permits it) - Ant2 will |
| not guarantee this behavior but will allow build file writers to |
| specify the order explicitly.</li> |
| |
| </ul> |
| |
| <h2>Support Integration of Ant Into Other Tools</h2> |
| |
| <p>Ant2 will have a clear separation between the front-end that is |
| responsible for user interactions, the object model that |
| represents the project to build and the part of Ant that runs the |
| build process itself <i class="comment">Name that TaskEngine, |
| ProjectEngine, ExecutionEngine or what?</i>. This separation is |
| expected to ease the integration of Ant (or parts of it) into |
| other products.</p> |
| |
| <p>Ant2 itself will include a command line front-end and Antidote |
| will become the GUI front-end to it. Other front-ends like a |
| servlet front-end are expected <i class="comment">outside of |
| Ant's core</i> as well.</p> |
| |
| <p>In addition to this separation, the following features should |
| help people who want to integrate Ant into their products:</p> |
| |
| <ul> |
| |
| <li>It will be possible to cancel a running build process.</li> |
| |
| <li>Ant will detach from <code>System.err/.out/.in</code> |
| completely and communicate with the front-end via a well defined |
| API. The front-end will have to handle user input for tasks |
| that need it (tasks that ask for a password for example).</li> |
| |
| <li>Tasks will provide some way to identify their attributes |
| from the outside. <i class="default">fill in details</i></li> |
| |
| </ul> |
| |
| <h2>More Control for Users and Build File Writers</h2> |
| |
| <p>Ant2 will use a <code>BuildListener</code> concept similar to |
| the one of Ant1 but may provide a richer set of events. It will be |
| possible to attach and detach listeners to a build process from |
| within the build file and to modify the behavior of attached |
| listeners.</p> |
| |
| <p>In Ant1 users have little control over how things work. There |
| are a couple of magic properties to make Ant chose a preferred |
| compiler or modify the CLASSPATH, but they are barely documented. |
| If users want to set these properties for every build process, |
| they have to learn the undocumented tricks of the |
| <code>ANT_OPTS</code> environment variable or the |
| <code>~/.antrc</code> file.</p> |
| |
| <p>Ant2 will have a well defined system to specify user |
| preferences. This system will not only let user chose their |
| compiler but also give them a chance to provide default values for |
| attributes (say you always want the <code>debug</code> attribute |
| of the <code>javac</code> task to be true - unless it has been |
| disabled explicitly). <i class="comment">Need to give details once |
| they've been sorted out.</i></p> |
| |
| <h2>Documentation System</h2> |
| |
| <p>All tasks will be documented in XML files using a common DTD <i |
| class="comment">Still need to define it</i> - task libraries are |
| expected to include the documentation using this DTD inside the |
| library itself.</p> |
| |
| <h2>Better Subbuild Handling</h2> |
| |
| <p class="comment">Is there something beyond "should become |
| better" right now?</p> |
| |
| <h2>Data Types</h2> |
| |
| <p>Ant1 supports a limited set of data types (fileset, patternset |
| and path) and at least up to Ant 1.3 it is not possible to |
| register custom data types without writing a task that does this. |
| Ant2 will provide a built-in mechanism to define new data |
| types.</p> |
| |
| <p>Existing data-types will be improved, the files in a fileset |
| can be chosen based on more than just pattern matching for example |
| (modification time or permissions for example). Ant2 will have |
| built-in tasks for set operations.</p> |
| |
| <p>Data types and properties will share the same name space and |
| follow the same scoping and precedence rules. |
| <i class="comment">${} again.</i></p> |
| |
| <h2>Multi-Threading of Tasks Within a Target</h2> |
| |
| <p>It will be possible to run several tasks in parallel - these |
| tasks will belong to the same target and all tasks will be joined |
| at the end of the target.</p> |
| |
| <h2>Internationalization</h2> |
| |
| <p>Ant2 itself will provide internationalized (error) messages and |
| provide utility classes to help task writers to do the same. |
| <i class="comment">These utility classes may very well come from a |
| different (Jakarta) project</i>.</p> |
| |
| <p>Ant's primary language and the language of the build file |
| will continue to be English.</p> |
| |
| <h1>Rejected Features</h1> |
| |
| <p>This is list is not complete, it just highlights some of the |
| rejected features and tries to explain why they've been |
| rejected. Two very common reasons to reject something were, that |
| the request has been too vague or the same functionality could |
| already be provided by some other accepted new feature.</p> |
| |
| <p>For a complete listing of all requested features, see <a |
| href="requested-features.html">requested-features.html</a>. The |
| discussion on all topics can be followed in the <a |
| href="http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2">archives |
| for ant-dev</a> in threads starting from 2001-03-21 - the subject |
| lines contained either <code>[VOTE]</code> or |
| <code>[DISC]</code>.</p> |
| |
| <h2>Simple Flow-Control</h2> |
| |
| <p>People asking for these kind of things have often heard the |
| standard "Ant shall not become yet another scripting language, Ant |
| shall not fall into the same traps make/Perl did ..." response |
| from the committers and some long-term ant-dev people.</p> |
| |
| <p>The long version of that answer is:</p> |
| |
| <ul> |
| <li>There are lots of open source scripting languages, there is |
| no need to define a new one.</li> |
| |
| <li>Ant has been created to be a build tool. While you can use |
| it for a whole lot of other things, this is not Ant's primary |
| focus (and it shouldn't be). Most use-cases that ask for |
| flow-control are out of Ant's scope.</li> |
| |
| <li>Ant already provides the requested functionality for many |
| common situations. The execon and apply tasks can be used to |
| iterate over a set of files as the (planed for Ant2) javaon and |
| anton tasks will do.</li> |
| |
| <li>Providing flow-control inside Ant's core would increase the |
| complexity of this core. This would make it difficult for new |
| contributors to understand how Ant works and increase the |
| maintenance cost for Ant at the same time. The goal of the Ant |
| developers is to push as much complexity and functionality out |
| of Ant's core into the tasks as possible.</li> |
| </ul> |
| |
| <p>That being said, Ant2 will make it easy to write iteration or |
| conditional tasks via the new container task concept. We expect |
| foreach, switch and if tasks to be written, but they will probably |
| not become core parts of the Ant distribution.</p> |
| |
| <h2>Advanced Conditionals for if/unless Attributes</h2> |
| |
| <p>The argument here is the same as for flow-control. We are |
| talking about complexity that can be pushed from the core to tasks |
| - and that is what will be done. Instead of additional power for |
| the if/unless attributes, Ant2 will have a new task that can set |
| properties based on the values of other properties or logical |
| combinations of other conditions, something like (making up |
| syntax):</p> |
| |
| <pre> |
| <condition name="javamail-complete"> |
| <and> |
| <available class="javax.mail.Transport"/> |
| <available class="javax.activation.DataHandler"/> |
| </and> |
| </condition> |
| </pre> |
| |
| <p>will become possible</p> |
| |
| <h2>Multi-Threaded Execution of Targets</h2> |
| |
| <p>The general feeling was, that the combination of target |
| dependencies and multi-threading would soon become too complex, |
| especially since Ant2 will allow people to explicitly enforce the |
| order in which (independent) targets will be executed.</p> |
| |
| <p>This issue will be explored again later, it has not been |
| rejected for all time being, but it is out of scope for |
| Ant 2.0</p> |
| |
| <h1>Ideas for New Tasks and Tools</h1> |
| |
| <p>Please refer to <a |
| href="requested-features.html">requested-features.html</a> in the |
| section "I. Things that don't affect the core but are |
| requests for new tasks or enhancements to existing tasks." |
| for this.</p> |
| |
| <hr> |
| <p align="center">$Id$</p> |
| <p align="center">Copyright © 2001 Apache Software |
| Foundation. All rights Reserved.</p> |
| </body> |
| </html> |