Diagnostic Tests with Ant
Pages: 1, 2, 3, 4, 5

If you create a custom task, its class has to extend the org.apache.tools.ant.Task class. Each attribute of the task in the build file gets set with a set method. The name of the setter method begins with "set", followed by the name of the attribute, with the first letter capitalized (this is the JavaBeans convention). For example, the attribute minVersion gets set with the method setMinVersion, while the attribute property gets set with the method setProperty.

The execute method gets performed when the task gets called in the build file. First we test if the attributes are set. Then we do the core of our task: if the installed Java version is greater than or equal to the minimum required Java version, we set the value of the property with the specified name to true.

The versions are stored as String objects. Therefore, we compare them with the compareTo method, which compares two Strings alphabetically. This method returns -1 when the first String comes before the second, 0 when the two Strings are equal, and +1 when the first String comes after the second alphabetically. This way, the task treats 1.5 as greater than 1.4, and also as greater than 1.4.2 or 1.4.2_05.

To use our custom task in the Ant build file, we first define a build property that contains the minimal required Java version:

<property name="minJavaVersion" value="1.5"/>

In the target systemProperties we add the following code:

<taskdef name="javaversion" 
 classname="JavaVersionTask" classpath="."/>
    <javaversion minVersion="${minJavaVersion}" 
    property="javaversion.ok"/>

The first line defines a new task with name javaversion, followed by the name of the Java class implementing this task, JavaVersionTask. The next line executes the javaversion task with the minimum required Java version specified. The property javaversion.ok gets a value when the installed Java version is greater than the specified version.

Then we add a target javaVersion:

<target name="javaVersion" 
 unless="javaversion.ok">
    <echo level="error" message="ERROR: Java 
        version too old: found ${java.version}, 
        needs ${minJavaVersion}."/>
  </target>

Next, we add the target to the dependencies of the target all. It only gets executed if the property javaversion.ok isn't set. If so, the target shows an error message stating the found Java version and the required Java version. An example of the output:

javaVersion:     [echo] ERROR: Java version 
too old: found 1.4.2_05, needs 1.5.

Analogous to JavaVersionTask, we could also write a task to perform other version checks, such as for the versions of installed libraries or the operating system.

Changed Files

When problems occur, it's very important to know whether some files were changed after the installation. It's possible that the standard configuration has been changed or a replaced file is causing the problem. In order to investigate this, we can use Ant's Checksum: in the installation build file of our application we generate a checksum for each file, while in our diagnostic test we verify the checksums. This way we know which files have been changed after the installation, and the task narrows down the search for the cause of the problems.

For each important file that could have been changed, we can generate an MD5 checksum in the installation build file and verify it in the diagnostics build file. Of course, there is a difference between changed binary files and changed configuration files. The first shouldn't have changed, and a change in the second could have caused a problem, but not always.

Pages: 1, 2, 3, 4, 5

Next Page