Revised Hello World tutorial

manual/tutorial-HelloWorldWithAnt.html

@@ -77,7 +77,7 @@ java -jar build\jar\HelloWorld.jar</pre>
 it would falsify it!</p>
 
 <h2 id="four-steps">Four steps to a running application</h2>
-<p>After finishing the java-only step we have to think about our build process. We <em>have</em> to compile our code,
+<p>After finishing the Java-only step we have to think about our build process. We <em>have</em> to compile our code,
 otherwise we couldn't start the program. Oh&mdash;<q>start</q>&mdash;yes, we could provide a target for
 that. We <em>should</em> package our application.  Now it's only one class&mdash;but if you want to provide a download,
 no one would download several hundreds files ...  (think about a complex Swing GUI&mdash;so let us create a jar file. A
@@ -165,8 +165,8 @@ java -jar build\jar\HelloWorld.jar</pre></td>
 </table>
 
 <h2 id="enhance">Enhance the build file</h2>
-<p>Now that we have a working buildfile, we could do some enhancements: many time you are referencing the same
-directories, main-class and jar-name are hard coded, and while invoking you have to remember the right order of build
+<p>Now that we have a working buildfile, we could do some enhancements: many times you are referencing the same
+directories, main-class and jar-name are hardcoded, and while invoking you have to remember the right order of build
 steps.</p>
 <p>The first and second point would be addressed with <em>properties</em>, the third with a special property&mdash;an
 attribute of the <code>&lt;project&gt;</code> tag and the fourth problem can be solved using dependencies.</p>
@@ -234,9 +234,9 @@ main:
 BUILD SUCCESSFUL</pre>
 
 <h2 id="ext-libs">Using external libraries</h2>
-<p>Somehow told us not to use sys-statements. For log-statements we should use a Logging API&mdash;customizable to a
-high degree (including switching off during usual life (= not development) execution). We use Log4J for that,
-because</p>
+<p>Somebody told us not to use <code>System</code>-statements. For output, we should use a Logging
+API&mdash;customizable to a high degree (including switching off during usual life (= not development) execution). We
+use Log4J for that, because</p>
 <ul>
 <li>it is not part of the JDK (1.4+) and we want to show how to use external libs</li>
 <li>it can run under JDK 1.2 (as Ant)</li>
@@ -305,7 +305,7 @@ buildfile:</p>
 &lt;/project&gt;</pre>
 
 <p>In this example we start our application not via its <code>Main-Class</code> manifest-attribute, because we could not
-provide a jarname <em>and</em> a classpath. So add our class in the red line to the already defined path and start as
+provide a jar-name <em>and</em> a classpath. So add our class in the red line to the already defined path and start as
 usual. Running <kbd>ant</kbd> would give (after the usual compile stuff):</p>
 
 <pre class="output">[java] 0 [main] INFO oata.HelloWorld  - Hello World</pre>
@@ -320,14 +320,14 @@ usual. Running <kbd>ant</kbd> would give (after the usual compile stuff):</p>
 <li><code>-</code> separator</li>
 <li><code>Hello World</code> the message</li>
 </ul>
-<p>For another layout ... have a look inside Log4J's documentation about using other PatternLayout's.</p>
+<p>For another layout ... have a look inside Log4J's documentation about using other PatternLayouts.</p>
 
 <h2 id="config-files">Configuration files</h2>
 <p>Why we have used Log4J? "It's highly configurable"? No&mdash;all is hardcoded! But that is not the fault of
 Log4J&mdash;it's ours. We had coded <code class="code">BasicConfigurator.configure();</code> which implies a simple, but
 hardcoded configuration. More comfortable would be using a property file. In the Java source file, delete
 the <code class="code">BasicConfiguration</code> line from the <code class="code">main()</code> method (and the
-related <code>import</code> statement). Log4J will search then for a configuration as described in it's manual. Then
+related <code>import</code> statement). Log4J will search then for a configuration as described in its manual. Then
 create a new file <samp>src/log4j.properties</samp>. That's the default name for Log4J's configuration and using that
 name would make life easier&mdash;not only the framework knows what is inside, you too!</p>
 
@@ -364,8 +364,12 @@ start the application from that directory and these files will included into the
 built-in JUnit 4.12 you could start directly using it. Write a test class in <samp>src\HelloWorldTest.java</samp>:</p>
 
 <pre>
+package oata;
+
 import org.junit.Test;
 
+import static org.junit.Assert.fail;
+
 public class HelloWorldTest {
 
     @Test
@@ -412,11 +416,11 @@ junit instruction to our buildfile:</p>
 
     ...</pre>
 
-<p>We reuse the path to our own jar file as defined in run-target by giving it an ID and making it globally available.
-The <var>printsummary</var>=<q>yes</q> lets us see more detailed information than just a "FAILED" or "PASSED" message.
-How much tests failed? Some errors? <var>printsummary</var> lets us know.  The classpath is set up to find our classes.
-To run tests the <code>batchtest</code> here is used, so you could easily add more test classes in the future just by
-naming them <code>*Test.java</code>.  This is a common naming scheme.</p>
+<p>We reuse the path to our own jar file as defined in <q>run</q>-target by giving it an <var>id</var> and making it
+globally available.  The <var>printsummary</var>=<q>yes</q> lets us see more detailed information than just a "FAILED"
+or "PASSED" message.  How much tests failed? Some errors? <var>printsummary</var> lets us know.  The classpath is set up
+to find our classes.  To run tests the <code>batchtest</code> here is used, so you could easily add more test classes in
+the future just by naming them <code>*Test.java</code>.  This is a common naming scheme.</p>
 
 <p>After a <kbd>ant junit</kbd> you'll get:</p>
 
@@ -430,8 +434,9 @@ junit:
 BUILD SUCCESSFUL
 ...</pre>
 
-<p>We can also produce a report. Something that you (and other) could read after closing the shell ....  There are two
-steps: 1. let <code>&lt;junit&gt;</code> log the information and 2. convert these to something readable (browsable).<p>
+<p>We can also produce a report. Something that you (and others) could read after closing the shell ....  There are two
+steps: 1. let <code>&lt;junit&gt;</code> log the information and 2. convert these log files to something readable
+(browsable).<p>
 
 <pre>
     ...