1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
---|
2 | <html>
|
---|
3 | <head>
|
---|
4 | <meta http-equiv="Content-Language" content="en-us">
|
---|
5 | <title>Ant2 feature list</title>
|
---|
6 |
|
---|
7 | <style type="text/css">
|
---|
8 | .comment {
|
---|
9 | COLOR: #900000;
|
---|
10 | BACKGROUND: #ffa;
|
---|
11 | }
|
---|
12 | </style>
|
---|
13 |
|
---|
14 | </head>
|
---|
15 |
|
---|
16 | <body bgcolor="#FFFFFF">
|
---|
17 |
|
---|
18 | <p class="comment">If something looks like this, this is either a
|
---|
19 | request for input or a "REVISIT" marker or similar.</p>
|
---|
20 |
|
---|
21 | <h1>Ant2 Goals</h1>
|
---|
22 |
|
---|
23 | <p>Even though Ant2 is expected to be incompatible with the
|
---|
24 | current Ant1 series, it still has the same goals. Ant is a Java
|
---|
25 | based build tool and this remains the main focus of it. The
|
---|
26 | original goals of simplicity, understandability and extensibility
|
---|
27 | still stand and Ant2 will try to achieve them even better than
|
---|
28 | Ant1 does.</p>
|
---|
29 |
|
---|
30 | <h2>Simplicity and Understandability</h2>
|
---|
31 |
|
---|
32 | <p>These two goals are closely related. Ant build files shall be
|
---|
33 | easy to read and understand - at the same time it should be easy
|
---|
34 | to write a custom Ant task and to use the utility classes that
|
---|
35 | Ant2 provides.</p>
|
---|
36 |
|
---|
37 | <p>Ant2 shall be more consistent than Ant1 is - this means:</p>
|
---|
38 |
|
---|
39 | <ul>
|
---|
40 |
|
---|
41 | <li>core tasks will use the same attribute names for common
|
---|
42 | functionality</li>
|
---|
43 |
|
---|
44 | <li>similar tasks will be unified to use similar forms.</li>
|
---|
45 |
|
---|
46 | <li>different implementations for the same functionality will be
|
---|
47 | hidden behind facade tasks.</li>
|
---|
48 |
|
---|
49 | <li>properties and data types will be unified so that they share
|
---|
50 | the same namespace and inheritance rules. <i
|
---|
51 | class="comment">Need to talk about how ${} expansion works for
|
---|
52 | filesets and so on.</i></li>
|
---|
53 |
|
---|
54 | </ul>
|
---|
55 |
|
---|
56 | <p>Furthermore some things will have to become more explicit:</p>
|
---|
57 |
|
---|
58 | <ul>
|
---|
59 |
|
---|
60 | <li>remove all magic properties</li>
|
---|
61 |
|
---|
62 | <li>make build file writers explicitly state which
|
---|
63 | filters/filtersets a copy task will use</li>
|
---|
64 |
|
---|
65 | <li>add scoping rules for properties so that not all of them
|
---|
66 | will be inherited by sub-builds, only those that have been
|
---|
67 | specified explicitly. <i class="comment">Fill in details once
|
---|
68 | they've been sorted out.</i></li>
|
---|
69 |
|
---|
70 | </ul>
|
---|
71 |
|
---|
72 | <p>The front-ends for Ant2 shall be smart enough to automatically
|
---|
73 | detect the required libraries (like <code>tools.jar</code>), the
|
---|
74 | use of native scripts shall be kept to a minimum.</p>
|
---|
75 |
|
---|
76 | <p>Build file writers can attach a message to targets that will be
|
---|
77 | presented to the user if that target is going to be skipped (based
|
---|
78 | on the if/unless attribute of the target).</p>
|
---|
79 |
|
---|
80 | <p>Even though Ant installation already is quite simple in Ant1
|
---|
81 | (extract the archive and set two environment variables),
|
---|
82 | alternative ways to install Ant like using
|
---|
83 | <a href="http://java.sun.com/products/javawebstart/">Webstart</a> or
|
---|
84 | a "self-extracting" JAR file will be explored.</p>
|
---|
85 |
|
---|
86 | <h2>Extensibility</h2>
|
---|
87 |
|
---|
88 | <p>Ant2 like Ant1 uses build files written in XML as its main
|
---|
89 | input, but it will not be restricted to it. The core of Ant2 will
|
---|
90 | work on an object model of Project/Target/Task that is independent
|
---|
91 | of any external representation.</p>
|
---|
92 |
|
---|
93 | <p>As an extension of the current <code><taskdef></code>
|
---|
94 | concept, tasks can be bundled into task libraries (together with
|
---|
95 | data types and other utility classes). These task libraries are
|
---|
96 | special JAR archives that somehow describe the contained tasks to
|
---|
97 | Ant. Ant will automatically know all tasks contained in task
|
---|
98 | libraries that have been placed into a special directory - in
|
---|
99 | addition task libraries can be referenced and used in a build file
|
---|
100 | explicitly. <i class="comment">Fill in details once they've been
|
---|
101 | sorted out.</i></p>
|
---|
102 |
|
---|
103 | <p>It has become apparent, that several "aspects" of
|
---|
104 | tasks are so common that task writers find themselves duplicating
|
---|
105 | code all over again - things like classpath handling or "do
|
---|
106 | we stop the build if this task fails?" functionality for
|
---|
107 | example. Ant2 will provide a way to let the user attach an
|
---|
108 | "aspect handler" to a project - all attributes that live
|
---|
109 | in a certain namespace are going to be passed to this handler. <i
|
---|
110 | class="comment">Need to talk about TaskContext here.</i></p>
|
---|
111 |
|
---|
112 | <p>Ant2 will farm out common functionality from tasks into utility
|
---|
113 | classes so that task writers can benefit from a tested and stable
|
---|
114 | framework - they shouldn't need to deal with existing tasks
|
---|
115 | directly (like some tasks "abuse" the
|
---|
116 | <code><touch></code> task in Ant1).</p>
|
---|
117 |
|
---|
118 | <p>Ant2 will provide a way to define tasks that itself can have
|
---|
119 | tasks as child elements without knowing all defined tasks at
|
---|
120 | compile time. Discussions on ant-dev usually talk about
|
---|
121 | "container tasks" in this context.</p>
|
---|
122 |
|
---|
123 | <p>The only way to "include" common XML snippets so far
|
---|
124 | has been the usage of external SYSTEM entities, a mechanism that
|
---|
125 | is tied to DTDs and doesn't mix well with alternative
|
---|
126 | approaches like XML Schema. Ant2 will provide a built-in include
|
---|
127 | mechanism.</p>
|
---|
128 |
|
---|
129 | <h1>New/Modified Features</h1>
|
---|
130 |
|
---|
131 | <p>Ant2 will run the build process fully dynamically, which means
|
---|
132 | that task won't be instantiated before they are actually being run
|
---|
133 | and <code>${}</code> expansion will see the very latest value of a
|
---|
134 | property. It will be possible to reassign values of properties via
|
---|
135 | a built-in task.</p>
|
---|
136 |
|
---|
137 | <h2>Compatibility with Ant1</h2>
|
---|
138 |
|
---|
139 | <p>Ant2 is going to break Ant1 in several ways:</p>
|
---|
140 |
|
---|
141 | <ul>
|
---|
142 |
|
---|
143 | <li>Tasks written for Ant1 won't work in Ant2 as the API of
|
---|
144 | Ant's core and the names of utility classes are going to
|
---|
145 | change. There will probably be adaptors and utility classes to
|
---|
146 | ease the transition for task writers.</li>
|
---|
147 |
|
---|
148 | <li>Build files written for Ant1 will probably not be valid in
|
---|
149 | Ant2 or at least not yield the same results. It is expected that
|
---|
150 | Ant2 will come with a tool to translate Ant1 build files into
|
---|
151 | equivalent Ant2 versions</li>
|
---|
152 |
|
---|
153 | <li>magic properties like <code>build.compiler</code> may
|
---|
154 | disappear and be replaced by a different customization
|
---|
155 | concept.</li>
|
---|
156 |
|
---|
157 | <li>Ant2 is going to require a JDK version 1.2 or above and a
|
---|
158 | JAXP compliant parser version 1.1 or above.</li>
|
---|
159 |
|
---|
160 | <li>If you specify more than one target in another target's
|
---|
161 | depends attribute, Ant1 will execute these targets from left to
|
---|
162 | right (as long as the dependency tree permits it) - Ant2 will
|
---|
163 | not guarantee this behavior but will allow build file writers to
|
---|
164 | specify the order explicitly.</li>
|
---|
165 |
|
---|
166 | <li>Dereferencing a non existent property a via ${a} will result
|
---|
167 | in a build failure.</li>
|
---|
168 |
|
---|
169 | </ul>
|
---|
170 |
|
---|
171 | <h2>Support Integration of Ant Into Other Tools</h2>
|
---|
172 |
|
---|
173 | <p>Ant2 will have a clear separation between the front-end that is
|
---|
174 | responsible for user interactions, the object model that
|
---|
175 | represents the project to build and the part of Ant that runs the
|
---|
176 | build process itself <i class="comment">Name that TaskEngine,
|
---|
177 | ProjectEngine, ExecutionEngine or what?</i>. This separation is
|
---|
178 | expected to ease the integration of Ant (or parts of it) into
|
---|
179 | other products.</p>
|
---|
180 |
|
---|
181 | <p>Ant2 itself will include a command line front-end and Antidote
|
---|
182 | will become the GUI front-end to it. Other front-ends like a
|
---|
183 | servlet front-end are expected <i class="comment">outside of
|
---|
184 | Ant's core</i> as well.</p>
|
---|
185 |
|
---|
186 | <p>In addition to this separation, the following features should
|
---|
187 | help people who want to integrate Ant into their products:</p>
|
---|
188 |
|
---|
189 | <ul>
|
---|
190 |
|
---|
191 | <li>It will be possible to cancel a running build process.</li>
|
---|
192 |
|
---|
193 | <li>Ant will detach from <code>System.err/.out/.in</code>
|
---|
194 | completely and communicate with the front-end via a well defined
|
---|
195 | API. The front-end will have to handle user input for tasks
|
---|
196 | that need it (tasks that ask for a password for example).</li>
|
---|
197 |
|
---|
198 | <li>Tasks will provide some way to identify their attributes
|
---|
199 | from the outside. <i class="default">fill in details</i></li>
|
---|
200 |
|
---|
201 | </ul>
|
---|
202 |
|
---|
203 | <h2>More Control for Users and Build File Writers</h2>
|
---|
204 |
|
---|
205 | <p>Ant2 will use a <code>BuildListener</code> concept similar to
|
---|
206 | the one of Ant1 but may provide a richer set of events. It will be
|
---|
207 | possible to attach and detach listeners to a build process from
|
---|
208 | within the build file and to modify the behavior of attached
|
---|
209 | listeners.</p>
|
---|
210 |
|
---|
211 | <p>In Ant1 users have little control over how things work. There
|
---|
212 | are a couple of magic properties to make Ant chose a preferred
|
---|
213 | compiler or modify the CLASSPATH, but they are barely documented.
|
---|
214 | If users want to set these properties for every build process,
|
---|
215 | they have to learn the undocumented tricks of the
|
---|
216 | <code>ANT_OPTS</code> environment variable or the
|
---|
217 | <code>~/.antrc</code> file.</p>
|
---|
218 |
|
---|
219 | <p>Ant2 will have a well defined system to specify user
|
---|
220 | preferences. This system will not only let user chose their
|
---|
221 | compiler but also give them a chance to provide default values for
|
---|
222 | attributes (say you always want the <code>debug</code> attribute
|
---|
223 | of the <code>javac</code> task to be true - unless it has been
|
---|
224 | disabled explicitly). <i class="comment">Need to give details once
|
---|
225 | they've been sorted out.</i></p>
|
---|
226 |
|
---|
227 | <h2>Documentation System</h2>
|
---|
228 |
|
---|
229 | <p>All tasks will be documented in XML files using a common DTD <i
|
---|
230 | class="comment">Still need to define it</i> - task libraries are
|
---|
231 | expected to include the documentation using this DTD inside the
|
---|
232 | library itself.</p>
|
---|
233 |
|
---|
234 | <h2>Better Subbuild Handling</h2>
|
---|
235 |
|
---|
236 | <p class="comment">Is there something beyond "should become
|
---|
237 | better" right now?</p>
|
---|
238 |
|
---|
239 | <h2>Data Types</h2>
|
---|
240 |
|
---|
241 | <p>Ant1 supports a limited set of data types (fileset, patternset
|
---|
242 | and path) and at least up to Ant 1.3 it is not possible to
|
---|
243 | register custom data types without writing a task that does this.
|
---|
244 | Ant2 will provide a built-in mechanism to define new data
|
---|
245 | types.</p>
|
---|
246 |
|
---|
247 | <p>Existing data-types will be improved, the files in a fileset
|
---|
248 | can be chosen based on more than just pattern matching for example
|
---|
249 | (modification time or permissions for example). Ant2 will have
|
---|
250 | built-in tasks for set operations.</p>
|
---|
251 |
|
---|
252 | <p>Data types and properties will share the same name space and
|
---|
253 | follow the same scoping and precedence rules.
|
---|
254 | <i class="comment">${} again.</i></p>
|
---|
255 |
|
---|
256 | <h2>Multi-Threading of Tasks Within a Target</h2>
|
---|
257 |
|
---|
258 | <p>It will be possible to run several tasks in parallel - these
|
---|
259 | tasks will belong to the same target and all tasks will be joined
|
---|
260 | at the end of the target.</p>
|
---|
261 |
|
---|
262 | <h2>Internationalization</h2>
|
---|
263 |
|
---|
264 | <p>Ant2 itself will provide internationalized (error) messages and
|
---|
265 | provide utility classes to help task writers to do the same.
|
---|
266 | <i class="comment">These utility classes may very well come from a
|
---|
267 | different (Jakarta) project</i>.</p>
|
---|
268 |
|
---|
269 | <p>Ant's primary language and the language of the build file
|
---|
270 | will continue to be English.</p>
|
---|
271 |
|
---|
272 | <h1>Rejected Features</h1>
|
---|
273 |
|
---|
274 | <p>This is list is not complete, it just highlights some of the
|
---|
275 | rejected features and tries to explain why they've been
|
---|
276 | rejected. Two very common reasons to reject something were, that
|
---|
277 | the request has been too vague or the same functionality could
|
---|
278 | already be provided by some other accepted new feature.</p>
|
---|
279 |
|
---|
280 | <p>For a complete listing of all requested features, see <a
|
---|
281 | href="requested-features.html">requested-features.html</a>. The
|
---|
282 | discussion on all topics can be followed in the <a
|
---|
283 | href="http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2">archives
|
---|
284 | for ant-dev</a> in threads starting from 2001-03-21 - the subject
|
---|
285 | lines contained either <code>[VOTE]</code> or
|
---|
286 | <code>[DISC]</code>.</p>
|
---|
287 |
|
---|
288 | <h2>Simple Flow-Control</h2>
|
---|
289 |
|
---|
290 | <p>People asking for these kind of things have often heard the
|
---|
291 | standard "Ant shall not become yet another scripting language, Ant
|
---|
292 | shall not fall into the same traps make/Perl did ..." response
|
---|
293 | from the committers and some long-term ant-dev people.</p>
|
---|
294 |
|
---|
295 | <p>The long version of that answer is:</p>
|
---|
296 |
|
---|
297 | <ul>
|
---|
298 | <li>There are lots of open source scripting languages, there is
|
---|
299 | no need to define a new one.</li>
|
---|
300 |
|
---|
301 | <li>Ant has been created to be a build tool. While you can use
|
---|
302 | it for a whole lot of other things, this is not Ant's primary
|
---|
303 | focus (and it shouldn't be). Most use-cases that ask for
|
---|
304 | flow-control are out of Ant's scope.</li>
|
---|
305 |
|
---|
306 | <li>Ant already provides the requested functionality for many
|
---|
307 | common situations. The execon and apply tasks can be used to
|
---|
308 | iterate over a set of files as the (planed for Ant2) javaon and
|
---|
309 | anton tasks will do.</li>
|
---|
310 |
|
---|
311 | <li>Providing flow-control inside Ant's core would increase the
|
---|
312 | complexity of this core. This would make it difficult for new
|
---|
313 | contributors to understand how Ant works and increase the
|
---|
314 | maintenance cost for Ant at the same time. The goal of the Ant
|
---|
315 | developers is to push as much complexity and functionality out
|
---|
316 | of Ant's core into the tasks as possible.</li>
|
---|
317 | </ul>
|
---|
318 |
|
---|
319 | <p>That being said, Ant2 will make it easy to write iteration or
|
---|
320 | conditional tasks via the new container task concept. We expect
|
---|
321 | foreach, switch and if tasks to be written, but they will probably
|
---|
322 | not become core parts of the Ant distribution.</p>
|
---|
323 |
|
---|
324 | <h2>Advanced Conditionals for if/unless Attributes</h2>
|
---|
325 |
|
---|
326 | <p>The argument here is the same as for flow-control. We are
|
---|
327 | talking about complexity that can be pushed from the core to tasks
|
---|
328 | - and that is what will be done. Instead of additional power for
|
---|
329 | the if/unless attributes, Ant2 will have a new task that can set
|
---|
330 | properties based on the values of other properties or logical
|
---|
331 | combinations of other conditions, something like (making up
|
---|
332 | syntax):</p>
|
---|
333 |
|
---|
334 | <pre>
|
---|
335 | <condition name="javamail-complete">
|
---|
336 | <and>
|
---|
337 | <available class="javax.mail.Transport"/>
|
---|
338 | <available class="javax.activation.DataHandler"/>
|
---|
339 | </and>
|
---|
340 | </condition>
|
---|
341 | </pre>
|
---|
342 |
|
---|
343 | <p>will become possible</p>
|
---|
344 |
|
---|
345 | <h2>Multi-Threaded Execution of Targets</h2>
|
---|
346 |
|
---|
347 | <p>The general feeling was, that the combination of target
|
---|
348 | dependencies and multi-threading would soon become too complex,
|
---|
349 | especially since Ant2 will allow people to explicitly enforce the
|
---|
350 | order in which (independent) targets will be executed.</p>
|
---|
351 |
|
---|
352 | <p>This issue will be explored again later, it has not been
|
---|
353 | rejected for all time being, but it is out of scope for
|
---|
354 | Ant 2.0</p>
|
---|
355 |
|
---|
356 | <h1>Ideas for New Tasks and Tools</h1>
|
---|
357 |
|
---|
358 | <p>Please refer to <a
|
---|
359 | href="requested-features.html">requested-features.html</a> in the
|
---|
360 | section "I. Things that don't affect the core but are
|
---|
361 | requests for new tasks or enhancements to existing tasks."
|
---|
362 | for this.</p>
|
---|
363 |
|
---|
364 | <hr>
|
---|
365 | <p align="center">$Id: features.html,v 1.6 2001/10/31 07:59:07 bodewig Exp $</p>
|
---|
366 | <p align="center">Copyright © 2001 Apache Software
|
---|
367 | Foundation. All rights Reserved.</p>
|
---|
368 | </body>
|
---|
369 | </html>
|
---|