corrections by Larry Schatzer

git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@276194 13f79535-47bb-0310-9956-ffa450edef68

docs/ant_in_anger.html

@@ -218,7 +218,7 @@ External Tools and Tasks page
 
 <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 @@ 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">&lt;fixCRLF&gt;</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 heirarchy which matches
+    <td>source goes in under this tree <i>in a hierarchy which matches
     the package names<i>. The dependency rules of &lt;javac&gt; 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 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 @@ 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 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 @@ 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 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 @@ 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 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 @@ 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 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 @@ 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 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 @@ 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 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 @@ 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
-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 @@ 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 &copy; 2000-2003 Apache Software Foundation. All rights
+<p align="center">Copyright &copy; 2000-2004 The Apache Software Foundation. All rights
 Reserved.</p>
 </body>