diff options
| author | Gintas Grigelionis <gintas@apache.org> | 2018-02-08 22:52:33 +0100 |
|---|---|---|
| committer | Gintas Grigelionis <gintas@apache.org> | 2018-02-08 22:52:33 +0100 |
| commit | 5266b79bb882f1912afa57abb1f19de6f03485e0 (patch) | |
| tree | c951c30a28158a2a46438c50c7e7984149d17a01 /manual/tutorial-HelloWorldWithAnt.html | |
| parent | 94d36a9fe7ba4f1bcb18a0501d57f72b75883d44 (diff) | |
| download | ant-5266b79bb882f1912afa57abb1f19de6f03485e0.tar.gz | |
Tidy tag soup, trim whitespace, fix styling
Diffstat (limited to 'manual/tutorial-HelloWorldWithAnt.html')
| -rw-r--r-- | manual/tutorial-HelloWorldWithAnt.html | 92 |
1 files changed, 34 insertions, 58 deletions
diff --git a/manual/tutorial-HelloWorldWithAnt.html b/manual/tutorial-HelloWorldWithAnt.html index babd9b43c..938204593 100644 --- a/manual/tutorial-HelloWorldWithAnt.html +++ b/manual/tutorial-HelloWorldWithAnt.html @@ -22,29 +22,25 @@ <body> <h1>Tutorial: Hello World with Apache Ant</h1> -<p>This document provides a step by step tutorial for starting java programming with Apache Ant. +<p>This document provides a step by step tutorial for starting Java programming with Apache Ant. It does <b>not</b> contain deeper knowledge about Java or Ant. This tutorial has the goal to let you see, how to do the easiest steps in Ant.</p> - - <h2>Content</h2> -<p><ul> +<ul> <li><a href="#prepare">Preparing the project</a></li> <li><a href="#four-steps">Enhance the build file</a></li> <li><a href="#enhance">Enhance the build file</a></li> <li><a href="#ext-libs">Using external libraries</a></li> <li><a href="#resources">Resources</a></li> -</ul></p> - +</ul> -<a name="prepare"></a> -<h2>Preparing the project</h2> +<h2 id="prepare">Preparing the project</h2> <p>We want to separate the source from the generated files, so our java source files will be in <tt>src</tt> folder. All generated files should be under <tt>build</tt>, and there splitted into several subdirectories for the individual steps: <tt>classes</tt> for our compiled files and <tt>jar</tt> for our own JAR-file.</p> -<p>We have to create only the <tt>src</tt> directory. (Because I am working on Windows, here is +<p>We have to create only the <tt>src</tt> directory. (Because I am working on Windows, here is the win-syntax - translate to your shell):</p> <pre class="code"> @@ -64,7 +60,7 @@ public class HelloWorld { } </pre> -<p>Now just try to compile and run that: +<p>Now just try to compile and run that:</p> <pre class="code"> md build\classes javac -sourcepath src -d build\classes src\oata\HelloWorld.java @@ -74,7 +70,6 @@ which will result in <pre class="output"> Hello World </pre> -</p> <p>Creating a jar-file is not very difficult. But creating a <i>startable</i> jar-file needs more steps: create a manifest-file containing the start class, creating the target directory and archiving the files.</p> @@ -85,12 +80,10 @@ jar cfm build\jar\HelloWorld.jar myManifest -C build\classes . java -jar build\jar\HelloWorld.jar </pre> -<p><b>Note:</b> Do not have blanks around the >-sign in the <tt>echo Main-Class</tt> instruction because it would +<p><b>Note:</b> Do not have blanks around the >-sign in the <tt>echo Main-Class</tt> instruction because it would falsify it!</p> - -<a name="four-steps"></a> -<h2>Four steps to a running application</h2> +<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 <i>have</i> to compile our code, otherwise we couldn't start the program. Oh - "start" - yes, we could provide a target for that. We <i>should</i> package our application. Now it's only one class - but if you want to provide a download, no one would download several hundreds files ... @@ -138,7 +131,7 @@ ant run ant compile jar run </pre> -<p>While having a look at the buildfile, we will see some similar steps between Ant and the java-only commands: +<p>While having a look at the buildfile, we will see some similar steps between Ant and the Java-only commands:</p> <table> <tr> <th>java-only</th> @@ -182,19 +175,14 @@ java -jar build\jar\HelloWorld.jar <java jar="build/jar/HelloWorld.jar" fork="true"/> </pre></td> </tr></table> -</p> - - -<a name="enhance"></a> -<h2>Enhance the build file</h2> +<h2 id="enhance">Enhance the build file</h2> <p>Now 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 invocation you have to remember the right order of build steps.</p> <p>The first and second point would be addressed with <i>properties</i>, the third with a special property - an attribute of the <project>-tag and the fourth problem can be solved using dependencies.</p> - <pre class="code"> <project name="HelloWorld" basedir="." default="main"> @@ -237,7 +225,6 @@ of the <project>-tag and the fourth problem can be solved using dependenci </project> </pre> - <p>Now it's easier, just do a <tt class="code">ant</tt> and you will get</p> <pre class="output"> Buildfile: build.xml @@ -260,16 +247,15 @@ main: BUILD SUCCESSFUL </pre> - -<a name="ext-libs"></a> -<h2>Using external libraries</h2> +<h2 id="ext-libs">Using external libraries</h2> <p>Somehow told us not to use syso-statements. For log-Statements we should use a Logging-API - customizable on a high -degree (including switching off during usual life (= not development) execution). We use Log4J for that, because <ul> +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> <li>it's highly configurable</li> <li>it's from Apache ;-)</li> -</ul></p> +</ul> <p>We store our external libraries in a new directory <tt>lib</tt>. Log4J can be <a href="http://www.apache.org/dist/logging/log4j/1.2.13/logging-log4j-1.2.13.zip">downloaded [1]</a> from Logging's Homepage. Create the <tt>lib</tt> directory and extract the log4j-1.2.9.jar into that lib-directory. After that we have to modify @@ -340,25 +326,24 @@ a jarname <i>and</i> a classpath. So add our class in the red line to the alread [java] 0 [main] INFO oata.HelloWorld - Hello World </pre> -<p>What's that? <ul> +<p>What's that?</p> +<ul> <li><i>[java]</i> Ant task running at the moment</li> <li><i>0</i> <font size="-1">sorry don't know - some Log4J stuff</font></li> <li><i>[main]</i> the running thread from our application </li> -<li><i>INFO</i> log level of that statement</i> -<li><i>oata.HelloWorld</i> source of that statement</i> + <li><i>INFO</i> log level of that statement</li> + <li><i>oata.HelloWorld</i> source of that statement</li> <li><i>-</i> separator</li> <li><i>Hello World</i> the message</li> </ul> -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 PatternLayout's.</p> -<a name="config-files"> -<h2>Configuration files</h2> +<h2 id="config-files">Configuration files</h2> <p>Why we have used Log4J? "It's highly configurable"? No - all is hard coded! But that is not the debt of Log4J - it's ours. We had coded <tt>BasicConfigurator.configure();</tt> which implies a simple, but hard coded configuration. More comfortable would be using a property file. In the java source delete the BasicConfiguration-line from the main() method -(and the related import-statement). Log4J will search then for a configuration as described in it's manual. Then create -a new file <tt>src/log4j.properties</tt>. That's the default name for Log4J's configuration and using that name would make +(and the related import-statement). Log4J will search then for a configuration as described in it's manual. Then create +a new file <tt>src/log4j.properties</tt>. That's the default name for Log4J's configuration and using that name would make life easier - not only the framework knows what is inside, you too!</p> <pre class="code"> @@ -389,9 +374,7 @@ finished yet. We should deliver the configuration file, too. So we change the bu <p>This copies all resources (as long as they haven't the suffix ".java") to the build directory, so we could start the application from that directory and these files will included into the jar.</p> - -<a name="junit"> -<h2>Testing the class</h2> +<h2 id="junit">Testing the class</h2> <p>In this step we will introduce the usage of the JUnit [3] testframework in combination with Ant. Because Ant has a built-in JUnit 3.8.2 you could start directly using it. Write a test class in <tt>src\HelloWorldTest.java</tt>: </p> @@ -400,14 +383,14 @@ public class HelloWorldTest extends junit.framework.TestCase { public void testNothing() { } - + public void testWillAlwaysFail() { fail("An error message"); } - + }</pre> -<p>Because we dont have real business logic to test, this test class is very small: just show how to start. For +<p>Because we dont have real business logic to test, this test class is very small: just show how to start. For further information see the JUnit documentation [3] and the manual of <a href="Tasks/junit.html">junit</a> task. Now we add a junit instruction to our buildfile:</p> @@ -424,14 +407,14 @@ Now we add a junit instruction to our buildfile:</p> </classpath> </java> </target> - + <b><target name="junit" depends="jar"> <junit printsummary="yes"> <classpath> <path refid="classpath"/> <path refid="application"/> </classpath> - + <batchtest fork="yes"> <fileset dir="${src.dir}" includes="*Test.java"/> </batchtest> @@ -462,7 +445,7 @@ BUILD SUCCESSFUL ... </pre> -<p>We can also produce a report. Something that you (and other) could read after closing the shell .... +<p>We can also produce a report. Something that you (and other) could read after closing the shell .... There are two steps: 1. let <junit> log the information and 2. convert these to something readable (browsable).<p> <pre class="code"> @@ -476,15 +459,15 @@ There are two steps: 1. let <junit> log the information and 2. convert the <path refid="classpath"/> <path refid="application"/> </classpath> - + <b><formatter type="xml"/></b> - + <batchtest fork="yes" <b>todir="${report.dir}"</b>> <fileset dir="${src.dir}" includes="*Test.java"/> </batchtest> </junit> </target> - + <b><target name="junitreport"> <junitreport todir="${report.dir}"> <fileset dir="${report.dir}" includes="TEST-*.xml"/> @@ -495,26 +478,19 @@ There are two steps: 1. let <junit> log the information and 2. convert the <p>Because we would produce a lot of files and these files would be written to the current directory by default, we define a report directory, create it before running the <tt>junit</tt> and redirect the logging to it. The log format -is XML so <tt>junitreport</tt> could parse it. In a second target <tt>junitreport</tt> should create a browsable +is XML so <tt>junitreport</tt> could parse it. In a second target <tt>junitreport</tt> should create a browsable HTML-report for all generated xml-log files in the report directory. Now you can open the ${report.dir}\index.html and see the result (looks something like JavaDoc).<br> Personally I use two different targets for junit and junitreport. Generating the HTML report needs some time and you dont need the HTML report just for testing, e.g. if you are fixing an error or a integration server is doing a job. </p> - - - -<a name="resources"></a> -<h2>Resources</h2> +<h2 id="resources">Resources</h2> <pre> [1] <a href="http://www.apache.org/dist/logging/log4j/1.2.13/logging-log4j-1.2.13.zip">http://www.apache.org/dist/logging/log4j/1.2.13/logging-log4j-1.2.13.zip</a> [2] <a href="http://logging.apache.org/log4j/docs/manual.html">http://logging.apache.org/log4j/docs/manual.html</a> [3] <a href="http://www.junit.org/index.htm">http://www.junit.org/index.htm</a> </pre> - - - </body> </html> |