ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ste...@apache.org
Subject cvs commit: ant/docs ant_in_anger.html
Date Fri, 05 Mar 2004 10:35:38 GMT
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">&lt;fixCRLF&gt;</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 &lt;javac&gt; 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 &copy; 2000-2003 Apache Software Foundation. All
rights
  +<p align="center">Copyright &copy; 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


Mime
View raw message