From 59d2888ac777b5aab93fcd2d080536fdfe2a5784 Mon Sep 17 00:00:00 2001 From: Gintas Grigelionis Date: Mon, 12 Mar 2018 06:42:44 +0100 Subject: [PATCH] Revised Hello World tutorial --- manual/tutorial-HelloWorldWithAnt.html | 37 +++++++++++++++----------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/manual/tutorial-HelloWorldWithAnt.html b/manual/tutorial-HelloWorldWithAnt.html index 41d64048d..b349babdc 100644 --- a/manual/tutorial-HelloWorldWithAnt.html +++ b/manual/tutorial-HelloWorldWithAnt.html @@ -77,7 +77,7 @@ java -jar build\jar\HelloWorld.jar it would falsify it!

Four steps to a running application

-

After finishing the java-only step we have to think about our build process. We have to compile our code, +

After finishing the Java-only step we have to think about our build process. We have to compile our code, otherwise we couldn't start the program. Oh—start—yes, we could provide a target for that. We should package our application. Now it's only one class—but if you want to provide a download, no one would download several hundreds files ... (think about a complex Swing GUI—so let us create a jar file. A @@ -165,8 +165,8 @@ java -jar build\jar\HelloWorld.jar

Enhance the build file

-

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 +

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.

The first and second point would be addressed with properties, the third with a special property—an attribute of the <project> tag and the fourth problem can be solved using dependencies.

@@ -234,9 +234,9 @@ main: BUILD SUCCESSFUL

Using external libraries

-

Somehow told us not to use sys-statements. For log-statements we should use a Logging API—customizable to a -high degree (including switching off during usual life (= not development) execution). We use Log4J for that, -because

+

Somebody told us not to use System-statements. For output, we should use a Logging +API—customizable to a high degree (including switching off during usual life (= not development) execution). We +use Log4J for that, because

-

For another layout ... have a look inside Log4J's documentation about using other PatternLayout's.

+

For another layout ... have a look inside Log4J's documentation about using other PatternLayouts.

Configuration files

Why we have used Log4J? "It's highly configurable"? No—all is hardcoded! But that is not the fault of Log4J—it's ours. We had coded BasicConfigurator.configure(); which implies a simple, but hardcoded configuration. More comfortable would be using a property file. In the Java source file, 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 +related import statement). Log4J will search then for a configuration as described in its manual. Then create a new file src/log4j.properties. 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!

@@ -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 src\HelloWorldTest.java:

+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:

 
     ...
-

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 printsummary=yes lets us see more detailed information than just a "FAILED" or "PASSED" message. -How much tests failed? Some errors? printsummary lets us know. The classpath is set up to find our classes. -To run tests the batchtest here is used, so you could easily add more test classes in the future just by -naming them *Test.java. This is a common naming scheme.

+

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 printsummary=yes lets us see more detailed information than just a "FAILED" +or "PASSED" message. How much tests failed? Some errors? printsummary lets us know. The classpath is set up +to find our classes. To run tests the batchtest here is used, so you could easily add more test classes in +the future just by naming them *Test.java. This is a common naming scheme.

After a ant junit you'll get:

@@ -430,8 +434,9 @@ junit: BUILD SUCCESSFUL ... -

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).

+

We can also produce a report. Something that you (and others) could read after closing the shell .... There are two +steps: 1. let <junit> log the information and 2. convert these log files to something readable +(browsable).

     ...