@@ -218,7 +218,7 @@ External Tools and Tasks page
<ul>
<li>
<a hef="http://checkstyle.sourceforge.net/">Checkstyle</a><br>
<a hr ef="http://checkstyle.sourceforge.net/">Checkstyle</a><br>
This tool audits your code and generates HTML reports of wherever any
style rule gets broken. Nobody can hide from the code police now! tip:
start using this early, so the corrections are less.
@@ -238,7 +238,7 @@ tags to your code you can have XDoclet automatically generate web.xml
descriptors, taglib descriptors, EJB interfaces, JMX interface classes,
Castor XML/SQL bindings, and many more. The key here is that all those
fiddly little XML files you need to create, and those interfaces EJB and
JMX requires to to implement, all can be autogenerated from your Java
JMX requires to implement, all can be autogenerated from your Java
code with a few helper attributes. This reduces
errors and means you can change your code and have the rest of the app
take its cue from the source. Never do EJB, JMX or webapps without it!
@@ -316,7 +316,7 @@ some application you are calling, or use the replace task to patch it
into a localised shell script or batch file.
<p>
Note that DOS descended file systems are case insensitive (apart from
the obscure aberration of the WinNT posix subsystem run against NTFS),
the obscure aberration of the WinNT POSIX subsystem run against NTFS),
and that Windows pretends that all file extensions with four or more
letters are also three letter extensions (try DELETE *.jav in your java
directories to see a disastrous example of this).
@@ -351,7 +351,7 @@ distributions, and is a simple download for <a href=
ActiveState</a>. A Perl file with .pl extension, with the usual Unix
path to perl on the line 1 comment and marked as executable can be run
on Windows, OS/2 and Unix and hence called from Ant without issues. The
perl code can be left to resolve its own platform issues. Dont forget to
perl code can be left to resolve its own platform issues. Don' t forget to
set the line endings of the file to the appropriate platform when you
redistribute Perl code; <a
href="manual/CoreTasks/fixcrlf.html"><fixCRLF></a>
@@ -493,7 +493,7 @@ The project contains sub directories
<tr>
<td><b>src</b>
</td>
<td>source goes in under this tree <i>in a he irarchy which matches
<td>source goes in under this tree <i>in a hie rarchy which matches
the package names<i>. The dependency rules of <javac> requires this.
</td>
</tr>
@@ -504,11 +504,11 @@ Slight variations include an extra tree of content to be included in the
distribution jars -inf files, images, etc. These can go under source
too, with a <tt>metadata</tt> directory for web.xml and similar
manifests, and a <tt>web</tt> folder for web content -JSP, html, images
and so on. Keeping the content in this folder (or sub he irarchy)
and so on. Keeping the content in this folder (or sub hie rarchy)
together makes it easier to test links before deployment. The actual
production of a deployment image -such as a war file- can be left to the
appropriate Ant task: there is no need to completely model your source tree
upon the deployment he irarchy.
upon the deployment hie rarchy.
<p>
Javadoc output can be
@@ -555,7 +555,7 @@ an automated, continuous, background build process.
Tightly coupled projects have all the source in the same tree; different
projects own different subdirectories. Build files can be moved down to
those subdirectores (say src/com/iseran/core and src/com/iseran/extras),
those subdirectori es (say src/com/iseran/core and src/com/iseran/extras),
or kept at the top -with independent build files named core.xml and
extras.xml
@@ -597,7 +597,7 @@ can be still be built.
The most aggressive strategy is to get a weekly or daily snapshot of the
ant source, build it up and use it. This forces you to tweak the
build.xml files more regulary, as new tasks and attributes can take
build.xml files more regularl y, as new tasks and attributes can take
while to stabilise. You really have to want the new features, enjoy
gratuitous extra work or take pleasure in upsetting your colleagues to
take this approach.
@@ -606,7 +606,7 @@ take this approach.
Once you start extending Ant with new tasks, it suddenly becomes much
more tempting to pull down regular builds. The most recent Ant builds
are invariably the the best platform for writing your extensions, as you
are invariably the best platform for writing your extensions, as you
can take advantage of the regular enhancements to the foundational
classes. It also prevents you from wasting time working on something
which has already been done. A newly submitted task to do something
@@ -727,7 +727,7 @@ Use Property Files
Use external property files to keep per-user settings out the build
files -especially passwords. Property files can also be used to
dynamically set a number of properties based on the value of a single
property, simply by dyamically generating the property filename from the
property, simply by dyn amically generating the property filename from the
source property. They can also be used as a source of constants across
multiple build files.
@@ -805,8 +805,8 @@ be called from any of your main build files, perhaps with subtly changed
parameters. Indeed, after a couple of projects you may be able to create
a re-usable core build file which contains the core targets of a basic
Java development project -compile, debug, deploy- which project specific
build files call with their own settings. If you can achive this then
you are defina tely making your way up the software maturity ladder. With
build files call with their own settings. If you can achie ve this then
you are defini tely making your way up the software maturity ladder. With
a bit of work you may progress from being a SEI CMM Level 0 organisation
"Individual Heroics are not enough" to SEI CMM Level 1, "Projects only
succeed due to individual heroics"
@@ -936,7 +936,7 @@ should contain a number of top level targets
<li>deploy - ship the jars, wars, whatever to the execution system
<li>publish - output the source and binaries to any distribution site
<li>fetch - get the latest source from the cvs tree
<li>docs/javadocs - do the documenation
<li>docs/javadocs - do the document ation
<li>all - clean, fetch, build, test, docs, deploy
<li>main - the default build process (usually build or build & test)
</ul>
@@ -1056,7 +1056,7 @@ Some of the features of make, specifically inference rules and
dependency checking are not included in Ant. That's because they are
'different' ways of doing a build. Make requires you to state
dependencies and the build steps, Ant wants you to state tasks and the
order between them, the tasks themselves can do depedency checking or
order between them, the tasks themselves can do depen dency checking or
not. A full java build using Jikes is so fast that dependency checking
is relatively moot, while many of the other tasks (but not all), compare
the timestamp of the source file with that of the destination file
@@ -1089,7 +1089,7 @@ and generally oversee the sub projects build processes. On a small project,
you don't need to do that -but remember: small projects become big projects
when you aren't looking. If you start off with a little bit of process, then
you can scale it if needed. If you start with none, by the time you need
it it will be too late.
it will be too late.
<h3>You still need all the other foundational bits of a software
project</h3>
@@ -1115,7 +1115,7 @@ to adapt to those changes which are inevitable.
Software development is meant to be fun. Being in the maelstrom of a
tight project with the stress of integration and trying to code
everything up for an insane deadline can be fun -it is certainly
exhili rating. Adding a bit of automation to the process may make things
exhila rating. Adding a bit of automation to the process may make things
less chaotic, and bit less entertaining, but it is a start to putting
you in control of your development process. You can still have fun, you
should just have less to worry about, a shorter build/test/deploy cycle
@@ -1131,7 +1131,7 @@ So get out there and have fun!
href="http://www.martinfowler.com/articles/continuousIntegration.html">
<i>Continuous Integration</i></a>; Martin Fowler. <br>
A paper on using Ant within a software project
running a continuous integration/testing proces.
running a continuous integration/testing process .
<li><i> Refactoring</i>; Martin Fowler, ISBN: 0201485672 <br>
Covers JUnit as well as tactics for making some headway with the mess of
code you will soon have.
@@ -1169,6 +1169,6 @@ so useful or as much fun).
For questions related to this document, use the Ant mailing list.
<hr>
<p align="center">Copyright © 2000-2003 Apache Software Foundation. All rights
<p align="center">Copyright © 2000-2004 The Apache Software Foundation. All rights
Reserved.</p>
</body>
Steve Loughran