3
Ant Task Design Guidelines
7
<h1>Ant Task Design Guidelines</h1>
9
This document covers how to write ant tasks to a standard required to be
10
incorporated into the ant distribution. You may find it useful when
11
writing tasks for personal use as the issues it addresses are still
15
<h2>Use built in helper classes</h2>
17
Ant includes helper tasks to simplify mauch of your work. Be warned that
18
these helper classes will look very different in ant2.0 from these 1.x
19
versions. However it is still better to use them than roll your own, for
20
development, maintenance and code size reasons.
24
Execute will spawn off separate programs under all the platforms which
25
ant supports, dealing with java version sublties as well as platform
26
issues. Always use this task to invoke other programs.
28
<h4>Java, ExecuteJava</h4>
30
These classes can be used to spawn java programs in a separate VM (they
31
use execute) or in the same VM -with or without a different classloader.
35
Project has some helper functions to touch a file, to
36
copy a file and the like. Use these instead of trying to code them
37
yourself -or trying to use tasks which may be less stable and fiddlier
41
<h2>Obey the Sun/Java style guidelines</h2>
43
The Ant codebase aims to have a single unified coding standard, and that
45
<a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">
46
Sun Java coding guidelines
50
It's not that they are better than any alternatives, but they are a
51
standard and they are what is consistently used in the rest of the
52
tasks. Code will not be incorporated into the database until it complies
57
If you are writing a task for your personal or organisational use, you
58
are free to use whatever style you like. But using the Sun Java style
59
will help you to become comfortable with the rest of the Ant source,
60
which may be important.
64
One controversial rule is 'no tabs'. Use four spaces instead. Not two,
65
not eight, four. Even if your editor is configured to have a tab of four
66
spaces, lots of others aren't -spaces have more consistency across
67
editors and platforms.
69
<h2>Recommended Names for attributes and elements</h2>
71
The ant1.x tasks are fairly inconsistent regarding naming of attributes
72
-some tasks use source, others src. Here is a list of what is likely to
73
be the preferred attribute names for ant 2.0.
75
<i>TODO: list attribute/element names which should be standardised, and meaning</i>
77
failonerror, source, dest...
79
<h2>Design for controlled re-use</h2>
81
Keep member variables private. If read access by subclasses is required.
82
add accessor methods rather than change the accessiblity of the member.
83
This enables subclasses to access the contents, yet
84
still be decoupled from the actual implementation.
87
The other common re-use mechanism in ant is for one task to create and
88
configure another. This is fairly simple. (TODO: example)
92
If the changes made to a task are making it too unwieldy, split it up
93
into a cleaner design, refactor the code and submit not just feature
94
creep but cleaner tasks. A common design pattern which tends to occur in
95
the ant process is the adoption of the adapter pattern, in which a base
96
class (say Javac or Rmi) starts off simple, then gets convoluted with
97
support for multiple back ends -javac, jikes, jvc. A refactoring to
98
split the programmable front end from the classes which provide the back
99
end cleans up the design and makes it much easier to add new back ends.
100
But to carry this off one needs to keep the interface and behaviour of
101
the front end identical, and to be sure that no subclasses have been
102
accessing data members directly -because these data members may not
103
exist in the refactored design. Which is why having private data members
109
Look in jakarta-ant/src/testcases and you will find Junit tests for the
110
shipping ant tasks, to see how it is done and what is expected of a new
111
task. Most of them are rudimentary, and no doubt you could do better for
112
your task -feel free to do so!
116
A well written set of test cases will break the ant task while it is in
117
development, until the code is actually complete. And every bug which
118
surfaces later should have a test case added to demonstrate the problem,
123
The test cases are a great way of testing your task during development.
124
A simple call to 'ant run-test' in the ant source tree will run all ant
125
tests, to verify that your changes don't break anything.
126
To test a single task, use the one shot <code>ant run-single-test
127
-Dtestcase=${testname}</code> where ${testname} is the name of your test class.
132
The test cases are also used by the committers to verify that changes
133
and patches do what they say. If you've got test cases it increases your
134
credibility significantly.
138
Remember also that ant 1.x is designed to compile and run on Java1.1, so
139
you should test on java 1.1 as well as any later version which you use.
140
If you are developing on Windows you may well have the Microsoft JVM at
141
hand for this, otherwise you can download an old SDK or runtime from
146
Without documentation, the task can't be used. So remember to provide a
147
succint and clear html (soon, xml) page describing the task in a similar
148
style to that of existing tasks. It should include a list of attributes
149
and elements, and at least one working example of the task. Many users
150
cut and paste the examples into their build files as a starting point,
151
so make the examples practical and test them too.
153
<h2>Licensing and Copyright</h2>
155
Any code submitted to the Apache project must be compatible with the
156
Apache Software License, and the act of submission must be viewed as an
157
implicit transfer of ownership of the submitted code to the Apache
165
The fairly laissez-faire license of Apache is not compabitible with
166
either the GPL or the Lesser GPL of the Free Software Foundation -the
167
Gnu project. Their license requires all changes to the source to be made
168
public, and give the licensee of any software the right to distribute
169
copies. It also requires derivative works to be made available under the
170
same license terms. None of these requirements are in the Apache Software
171
Foundation license, which permits people and organisations to build
172
commercial and closed source applications atop the Apache libraries and
173
source -but not use the Apache, Ant or Jakarta Project names without
178
Because the Gnu GPL license immediately extends to cover any larger
179
application (or library, in the case of GLPL) into which it is
180
incorporated, the Ant team can not incorporate any task based upon GPL
181
or LGPL source into the Ant codebase. You are free to submit it, but it
182
will be politely and firmly rejected.
186
Once ant-2 adds better dynamic task incorporation, it may be possible to
187
provide a framework for supporting [L]GPL code, but still no tasks
188
direcely subject to the Gnu licenses will ever be included in the Ant
191
<h3>Dont re-invent the wheel</h3>
193
We've all done it: written and submitted a task only to discover it
194
was already implemented in a small corner of another task, or it has
195
been submitted by someone else and not committed. You can avoid this
196
by being aware of what is in the latest CVS tree -keep getting the daily
197
source updates, look at manual changes and subscribe to the ant-dev
202
If you are thinking of writing a task, posting a note on your thoughts
203
to the list can be informative -you well get other peoples insight and
204
maybe some half written task to do the basics, all without writing a
208
<h2>Submitting to Ant</h2>
210
The process for submitting an ant task is documented on the
211
<a href="http://jakarta.apache.org/site/guidelines.html">
212
jakarta web site</a>.
213
The basic mechanism is to mail it to the ant-dev mailing list.
214
It helps to be on this list, as you will see other submissions, and
215
any debate about your own submission.
218
Patches to existing files should be generated with <code>cvs diff -u filename</code>
219
and save the output to a file. If you want to get
220
the changes made to multiple files in a directory , just use <code>cvs
221
diff -u</code>. The patches should be sent as an attachment to a message titled [PATCH]
222
and distinctive one-line summary in the subject of the patch. The
223
filename/task and the change usually suffices. It's important to include
224
the changes as an attachment, as too many mailers reformat the text
225
pasted in, which breaks the patch.
227
Then you wait for one of the committers to commit the patch, if it is
228
felt appropriate to do so. Bug fixes go in quickly, other changes
229
often spark a bit of discussion before a (perhaps revised) commit is
233
New submissions should be proceeded with [SUBMIT]. The mailer-daemon
234
will reject any messages over 100KB, so any large update should be
235
zipped up. If your submission is bigger than that, why not break it up
240
These are the things you should verify before submitting patches and new
241
tasks. Things don't have to be perfect, it may take a couple of
242
iterations before a patch or submission is committed, and these items
243
can be addressed in the process. But by the time the code is committed,
244
everything including the documentation and some test cases will have
245
been done, so by getting them out the way up front can save time.
246
The committers look more favourably on patches and submissions with test
247
cases, while documentation helps sell the reason for a task.
249
<h3>Checklist before submitting a patch</h3>
251
<li>Added code complies with style guidelines
252
<li>New member variables are private, and provide public accessor methods
253
if access is actually needed.
254
<li>Existing test cases succeed.
255
<li>New test cases written and succeed.
256
<li>Documentation page extended as appropriate.
257
<li>Example task declarations in the documentation tested.
258
<li>Diff files generated using cvs diff -u
259
<li>Message to ant-dev contains [PATCH], task name and patch reason in
261
<li>Message body contains a rationale for the patch.
262
<li>Message attachment contains the patch file(s).
265
<h3>Checklist before submitting a new task</h3>
267
<li>Java file begins with Apache copyright and license statement.
268
<li>Task does not depend on GPL or LGPL code.
269
<li>Source code complies with style guidelines
270
<li>Member variables are private, and provide public accessor methods
271
if access is actually needed.
272
<li><i>Maybe</i> Task has failonerror attribute to control failure behaviour
273
<li>New test cases written and succeed
274
<li>Documentation page written
275
<li>Example task declarations in the documentation tested.
276
<li>Patch files generated using cvs diff -u
277
<li>patch files include a patch to defaults.properties to register the
279
<li>patch files include a patch to coretasklist.html or
280
optionaltasklist.html to link to the new task page
281
<li>Message to ant-dev contains [SUBMIT] and task name in subject
282
<li>Message body contains a rationale for the task
283
<li>Message attachments contain the required files -source, documentation,
287
<p align="center">Copyright © 2001 Apache Software Foundation. All rights
added
removed
docs/ant_task_guidelines.html
