You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by st...@apache.org on 2004/03/05 11:35:38 UTC
cvs commit: ant/docs ant_in_anger.html
stevel 2004/03/05 02:35:38
Modified: docs ant_in_anger.html
Log:
corrections by Larry Schatzer
Revision Changes Path
1.17 +19 -19 ant/docs/ant_in_anger.html
Index: ant_in_anger.html
===================================================================
RCS file: /home/cvs/ant/docs/ant_in_anger.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ant_in_anger.html 9 Jul 2003 16:24:35 -0000 1.16
+++ ant_in_anger.html 5 Mar 2004 10:35:38 -0000 1.17
@@ -218,7 +218,7 @@
<ul>
<li>
-<a hef="http://checkstyle.sourceforge.net/">Checkstyle</a><br>
+<a href="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 @@
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 @@
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 @@
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 @@
<tr>
<td><b>src</b>
</td>
- <td>source goes in under this tree <i>in a heirarchy which matches
+ <td>source goes in under this tree <i>in a hierarchy which matches
the package names<i>. The dependency rules of <javac> requires this.
</td>
</tr>
@@ -504,11 +504,11 @@
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 heirarchy)
+and so on. Keeping the content in this folder (or sub hierarchy)
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 heirarchy.
+upon the deployment hierarchy.
<p>
Javadoc output can be
@@ -555,7 +555,7 @@
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 subdirectories (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 @@
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 regularly, 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 @@
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 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 dynamically 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 @@
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 definately making your way up the software maturity ladder. With
+build files call with their own settings. If you can achieve this then
+you are definitely 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 @@
<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 documentation
<li>all - clean, fetch, build, test, docs, deploy
<li>main - the default build process (usually build or build & test)
</ul>
@@ -1056,7 +1056,7 @@
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 dependency 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 @@
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 @@
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
-exhilirating. Adding a bit of automation to the process may make things
+exhilarating. 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 @@
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 @@
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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org