Wednesday, 15 April 2009

com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH]

Emma is used for finding the code coverage of JUnit test classes.

When running Emma with a JEE container, the source .class files (not the .java files) are first instrumented and then deployed on the J2EE server.

Then the test classes are executed from ant command line or via an Eclipse plug-in, and this will write out the coverage data into .em or .ec files.

Sometimes, an error observed when running Emma is
[report] processing input files ...
[report] 2 file(s) read and merged in 172 ms
[report] com.vladium.emma.EMMARuntimeException: [CLASS_STAMP_MISMATCH] runtime version of class [] in the coverage data is not consistent with the version of this class in the metadata, possibly because stale metadata is being used for report generation.

[report] at
[report] at
[report] at
[report] at

To calculate the coverage, EMMA combines data of two types:
metadata (static info about your Java classes, methods, lines, and basic blocks) and runtime coverage data (which basic blocks have been executed)

The error occurs when there is a mismatch in the versions of the classes used while recording the metadata.em and coverage.em files. The runtime version of the class in the coverage data is not consistent with the same class in the metadata

In simpler terms, the in-container application jars deployed on the JEE server are not in sync with the currently instrumented source from where the emma is being run, hence the class stamp difference in .emma files – metadata.em and coverage.em

Update -
A couple of comments posted below have some more checks and solutions to this problem.

Thursday, 2 April 2009

Running Maven offline using local Repository

Sometimes you see Maven downloading POM files for dependencies which are already in your local repository and you're wondering why it does this.


The reason it does is because when these were installed in the local repository, it was not given a flag of -Dgenerate.pom=true

If you run the install with this flag, then it will generate and install a local POM file for you, and will not download the POM from the internet repository.

An example below
mvn install:install-file -DgroupId=%GROUP_ID% -DartifactId=%ARTIFACT_ID% -Dversion=%VERSION% -Dfile=%COMPONENT%.jar -Dpackaging=jar -DgeneratePom=true

There are 2 other ways to run the build without connecting to the internet or network repository each time - provided you have all the required dependencies available offline.

Note: This is just something I do when I want to run a quick repeat build and I know there are no dependencies updated in the mean time. If you do this regularly you will miss out on updates made to the maven repository by other developers.

1. Run the maven build in offline mode

mvn -o install

NOTE: Maven is executing in offline mode. Any artifacts not already in your loca
repository will be inaccessible.


When you see this message, you know that maven will not be updating external dependencies during the build.

2. Point the repository to the local file system.

On my local build, if running repeated code builds when I know there is no change in dependency, I have a profile set up to point the repository to a local file system.

In the repository definition, instead of

use the file:// path


You will still see the message indicating downloading of POM, but this time from the local file system.
And this will be much faster.
Downloading: file://D:\mavenrepo\cactus\1.7.2\cactus-1.7.2.pom
Downloading: file://D:\mavenrepo\strutstest\2.1.3\strutstest-2.1.3.pom