About GroboUtils

• Welcome
• License
• Project List
• Contacts
• Articles

Sourceforge
Project

• Forums
• Bugs
• Feature Requests

For Developers

• Downloads
• Javadoc
• Dependencies
• Building

GroboCodeCoverage version 1.1.0

Author:Matt Albrecht

How GroboCoverage Works

GroboCoverage works by inserting "probes" into the post-compiled class files. These probes call out to a logger (more on that later), telling it which class, method index, and probe index was invoked.

During the post-compilation of the class files, a set of data files get generated, which record what a method index and probe index translate into with regards to the source file.

The reporting phase combines the post-compilation data files with the log data from the loggers to generate XML reports, and from that HTML reports using XSL-T.

The Logger

The base logger class (net.sourceforge.groboutils.codecoverage.v2.logger.CoverageLogger) gets called at each probe point through invoking its cover method, and redirects these invocations to the different registered channels (a channel in the logger corresponds to an analysis measure during post-compilation).

This static class discovers the registered channels at class load time through the /grobocoverage.properties file (relative to the classpath). If that resource isn't found, then the initialization uses the system properties.

The initialization routine creates a number of channels from the specified logger factory (whose fully-qualified class name is given in the properties with the key "factory"). The number of channels comes from the key "channel-count". All property keys starting with "logger." are passed to the factory class for initialization.

Currently, all logger implementations output the probe information to plain text files in a logging directory (specified by the key "logger.dir"), one file per class. The format of this file is simply a series of lines, each specifying a single probe:

    methodIndex,probeIndex

There can be duplicates of these method/probe pairs, which will be condensed down during report parsing. The filename reflects the class name with a CRC check (so different class files with the same name don't confuse the logger), and each channel outputs to its own sub-directory in this logging directory.

This means that if you have several coverage runs, logging to different directories (or even across machines), all you need to do is concatenate the files with the same name together (order isn't important), and copy the one-off log files into those directories. The reporting task will do the rest

However, an alternate logger style, called the "single" style, puts all the logging data into a single file. It requires modifying the <grobo-report> task slightly, but makes for a much easier merge on the files. In order to prevent some classloader problems, this style can create multiple output files inside the log directory. Due to this, the report filter will scan that directory for all "single" files. This makes the task of merging multiple files moot - just copy all the "single" style files into the log directory, and generate the report. The output format looks like:

    channel,class signature,methodIndex,probeIndex

The Probes

Each probe added to the post-compiled class files adds several instructions to the bytecode. They setup the invocation to the static method in the CoverageLogger (see above) to reflect the current probe and current method.