Create a directory to hold your StackyHack system, such as "projects". Download the stackyhack.zip file into this directory. Unzipping the stackyhack.zip file will create a directory called stackyhack-X.Y.Z, where "X.Y.Z" provides the major, minor, and bugfix version numbers. The major and minor version numbers are coordinated with Hackystat development, and so these numbers will indicate that last Hackystat release cycle in which a StackyHack release was made.
![[Note]](gfx/admonitions/note.gif) | Note |
|---|---|
For Ant to function properly, there must be no spaces in the file path to the system directory. Thus, do not unzip the StackyHack distribution within a directory whose name contains spaces, such as "My Documents" or "Program Files". If the above link does not work, it is probably because you are reading this documentation from the version stored at the Hackystat Developer Services site. To obtain the .zip file, use the User Guide from the Help page of an installed Hackystat server, such as the Hackystat Public Server. | |
Example 4.1, “StackyHack distribution structure” illustrates the basic structure of the StackyHack system from a recent release of StackyHack. Your version may differ slightly from this example, typically in the set of *.build.xml files.
Example 4.1. StackyHack distribution structure
stackyhack-7.4.308/
.project
.classpath
build.xml
ant.build.xml
checkstyle.build.xml
dependencyfinder.build.xml
emma.build.xml
findbugs.build.xml
jblanket.build.xml
jira.build.xml
junit.build.xml
locc.build.xml
pmd.build.xml
sclc.build.xml
svn.build.xml
src/
edu/hawaii/stack/*.java
As illustrated, the StackyHack system consists of a top-level directory that contains two files for use with Eclipse (.project and .classpath) and several *.build.xml files that contain targets to invoke various tools and the Hackystat sensors associated with them. The top-level directory also contains a src/ directory containing a small amount of Java code to implement the Stack system.
The StackyHack system contains JUnit tests, so in order to compile the system for the first time, you must ensure that JUnit 4.1 is installed. To install JUnit for use in StackyHack, download the .zip file containing the JUnit 4 from its home page into a directory such as "java-tools", and unzip it. Then, define an environment variable called JUNIT_HOME that points to this directory.
Once you have unzipped the stackyhack system and installed JUnit, you can check to see that a basic build of the StackyHack works correctly by typing 'ant' in its top-level directory. Example 4.2, “Default Build of StackyHack” shows the output from this command.
Example 4.2. Default Build of StackyHack
C:\svn-csdl\StackyHack>ant
Buildfile: build.xml
compile:
[mkdir] Created dir: C:\svn-csdl\StackyHack\build\classes
[javac] Compiling 5 source files to C:\svn-csdl\StackyHack\build\classes
BUILD SUCCESSFUL
Total time: 0 seconds
As you can see, a default build of the Stack system simply compiles the source files and places them into a newly created build/ directory.
Once StackyHack successfully compiles, it is useful to take a brief look at the build.xml file, which shows the basic properties and targets in the build system. Example 4.3, “The StackyHack build.xml file” shows the build.xml file.
Example 4.3. The StackyHack build.xml file
<project name="stackyhack.build" default="compile">
<description>
The basic build file for the StackyHack system.
</description>
<!-- Always make environment variables available with the "env." prefix. -->
<property environment="env"/>
<!-- Make sure we're running a Java 5 or better. -->
<condition property="java.5.available">
<or>
<contains string="${java.version}" substring="1.5" />
<contains string="${java.version}" substring="1.6" />
</or>
</condition>
<fail message="This package requires Java 5 or 6." unless="java.5.available"/>
<!-- Make sure we're running Ant 1.7 . -->
<condition property="ant.1.7.available">
<contains string="${ant.version}" substring="1.7" />
</condition>
<fail message="This package requires Ant 1.7." unless="ant.1.7.available"/>
<!-- Make sure that JUnit is installed . -->
<available file="${env.JUNIT_HOME}" type="dir" property="junit.available"/>
<fail message="This package requires JUnit to be installed and JUNIT_HOME defined" unless="junit.available"/>
<!-- Basic properties for this system. -->
<property name="system.name" value="stackyhack" />
<property name="majorVersionNumber" value="7" />
<property name="minorVersionNumber" value="4" />
<tstamp><format property="DAYSTAMP" pattern="Mdd" /></tstamp>
<property name="version" value="${majorVersionNumber}.${minorVersionNumber}.${DAYSTAMP}" />
<!-- Hackystat sensor configuration information. -->
<property name="hackystat.verbose.mode" value="true" />
<!-- Basic directory structure. -->
<property name="src.dir" location="${basedir}/src" />
<property name="lib.dir" location="${basedir}/lib" />
<property name="build.dir" location="${basedir}/build" />
<!-- The compile classpath is useful to many tools. -->
<path id="compile.classpath">
<fileset file="${env.JUNIT_HOME}/junit*.jar"/>
</path>
<target name="compile" description="Compiles the code.">
<!-- Now compile the code into build/classes -->
<mkdir dir="${build.dir}/classes"/>
<javac srcdir="${src.dir}" destdir="${build.dir}/classes" source="1.4" debug="on" includeAntRuntime="no">
<classpath refid="compile.classpath" />
</javac>
</target>
<target name="clean" description="Delete build/ directory.">
<delete dir="${build.dir}" />
</target>
<target name="convertLineEndings" description="Makes *.build.xml line endings compatible with host platform.">
<fixcrlf srcdir="${basedir}" includes="*.build.xml"/>
</target>
</project>
The build.xml file defines some essential properties for the build, including the locations of subdirectories and so forth, and then defines the following targets: compile, clean, and convertLineEndings. The convertLineEndings target is useful if you wish to inspect the *.build.xml files in an editor and want the line endings appropriate to your host platform.
Note that the property "hackystat.verbose.mode" is set to true. This means that the sensors will generate extra output information when they are invoked. This is useful when you are first learning to use the sensors, or when you run into problems. In your own Ant files, you will probably want to set this attribute to be false by default, and then set it to true on the command line when you want additional debugging information, as follows:
ant -Dhackystat.verbose.mode=true <target>
You can, if you wish, take a few moments at this point to inspect the StackyHack system in more detail, looking at the various directories and files. The following sections show how to gather various product and process measures and send them to Hackystat.