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
emma.report:
[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 [com.xyz.action.MyAction] 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 com.vladium.emma.report.ReportDataModel.getView(ReportDataModel.java:95)
[report] at com.vladium.emma.report.AbstractReportGenerator.initialize(AbstractReportGenerator.java:207)
[report] at com.vladium.emma.report.html.ReportGenerator.process(ReportGenerator.java:85)
[report] at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:254)
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.