wip.emma.report:
[delete] Deleting directory C:\dch\ReEng\java\projects\ssl\reports\api\emma
[mkdir] Created dir: C:\dch\ReEng\java\projects\ssl\reports\api\emma
[report] processing input files ...
[report] 2 file(s) read and merged in 0 ms
[report] java.lang.IllegalArgumentException: null or empty input: name
[report] at com.vladium.util.Descriptors.combine(Descriptors.java:30)
[report] at com.vladium.util.Descriptors.combineVMName(Descriptors.java:45)
[report] at com.vladium.emma.report.ReportDataModel.getView(ReportDataModel.java:76)
[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)
[report] at com.vladium.emma.Processor.run(Processor.java:54)
[report] at com.vladium.emma.report.reportTask.execute(reportTask.java:77)
[report] at com.vladium.emma.emmaTask.execute(emmaTask.java:57)
[report] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
[report] at org.apache.tools.ant.Task.perform(Task.java:364)
[report] at org.apache.tools.ant.Target.execute(Target.java:301)
[report] at org.apache.tools.ant.Target.performTasks(Target.java:328)
[report] at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
[report] at org.apache.tools.ant.Project.executeTargets(Project.java:1063)
[report] at org.apache.tools.ant.Main.runBuild(Main.java:632)
[report] at org.apache.tools.ant.Main.startAnt(Main.java:183)
[report] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:197)
[report] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56)
The coverage.emma and metadata.emma files are ok (as far as I can tell).
I have other emma report targets that work ok, but this emma instrumentation was done against an obfuscated jar (marvin obfuscator 1.2b).
When running instrumentaton against class files on the disk, everthing is ok.
Emma version is 2.0.4217
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been reported elsewhere. This is caused by the obfuscator removing some info from the class files, info that is used by EMMA. The obfuscated classes are Ok to execute in the JVM but they are not valid from the class format point of view (e.g., they contain a SourceFile attribute with an empty class name string).
You should either not use obfuscation at all when doing coverage analysis or do EMMA instrumentation *before* obfuscation. An obfuscator will mangle your classes in a way that will prevent bytecode-to-source code linking anyway (rename methods, rearrange basic blocks, etc).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Appologies for not searching for a report before posting. So thanks for the reply. Could I turn this into a feature request?
What I want to do is run tests against the obfuscated jar (instrumented with a filter to only pick up only the non-obfuscated classes) to make sure all publicly visible methods (i.e. the api of the system in the jar) are invoked by the test cases.
Prior to this step I have run a super set of these test cases against the non obfuscated class files to ensure 100% code coverage.
The second step is to ensure 100% coverage of the api. I want to demonstrate that everything visible works (the api tests pass) and nothing is visible that should not be (the tests demonstrate 100% method invocation).
If the tests fail it should be because not enough is visible in the obfuscated jar (they passed against non-obfuscated code). If the tests pass but get less than 100% coverage - too much is visible in the jar.
Even if you don't adopt this idea, I'd be interested in your thoughts on it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am rather confused by this. It sounds like you do not expect EMMA to figure out which classes are obfuscated and which are not, because you will provide an appropriate instrumentation filter ("instrumented with a filter to only pick up only the non-obfuscated classes").
Since you can do this with the current version, what new EMMA functionality is needed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have this ant target:
<target name="wip.emma.report">
<delete dir="${reports}/api/emma"/>
<mkdir dir="${reports}/api/emma"/>
<emma>
<report>
<fileset dir="${tmp}/api" >
<include name="*.emma" />
</fileset>
<html
outfile="${reports}/api/emma/index.html"
depth="all"
columns="name,class,method"/>
</report>
</emma>
</target>
And this error:
wip.emma.report:
[delete] Deleting directory C:\dch\ReEng\java\projects\ssl\reports\api\emma
[mkdir] Created dir: C:\dch\ReEng\java\projects\ssl\reports\api\emma
[report] processing input files ...
[report] 2 file(s) read and merged in 0 ms
[report] java.lang.IllegalArgumentException: null or empty input: name
[report] at com.vladium.util.Descriptors.combine(Descriptors.java:30)
[report] at com.vladium.util.Descriptors.combineVMName(Descriptors.java:45)
[report] at com.vladium.emma.report.ReportDataModel.getView(ReportDataModel.java:76)
[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)
[report] at com.vladium.emma.Processor.run(Processor.java:54)
[report] at com.vladium.emma.report.reportTask.execute(reportTask.java:77)
[report] at com.vladium.emma.emmaTask.execute(emmaTask.java:57)
[report] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
[report] at org.apache.tools.ant.Task.perform(Task.java:364)
[report] at org.apache.tools.ant.Target.execute(Target.java:301)
[report] at org.apache.tools.ant.Target.performTasks(Target.java:328)
[report] at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
[report] at org.apache.tools.ant.Project.executeTargets(Project.java:1063)
[report] at org.apache.tools.ant.Main.runBuild(Main.java:632)
[report] at org.apache.tools.ant.Main.startAnt(Main.java:183)
[report] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:197)
[report] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56)
The coverage.emma and metadata.emma files are ok (as far as I can tell).
I have other emma report targets that work ok, but this emma instrumentation was done against an obfuscated jar (marvin obfuscator 1.2b).
When running instrumentaton against class files on the disk, everthing is ok.
Emma version is 2.0.4217
Any ideas?
This has been reported elsewhere. This is caused by the obfuscator removing some info from the class files, info that is used by EMMA. The obfuscated classes are Ok to execute in the JVM but they are not valid from the class format point of view (e.g., they contain a SourceFile attribute with an empty class name string).
You should either not use obfuscation at all when doing coverage analysis or do EMMA instrumentation *before* obfuscation. An obfuscator will mangle your classes in a way that will prevent bytecode-to-source code linking anyway (rename methods, rearrange basic blocks, etc).
Appologies for not searching for a report before posting. So thanks for the reply. Could I turn this into a feature request?
What I want to do is run tests against the obfuscated jar (instrumented with a filter to only pick up only the non-obfuscated classes) to make sure all publicly visible methods (i.e. the api of the system in the jar) are invoked by the test cases.
Prior to this step I have run a super set of these test cases against the non obfuscated class files to ensure 100% code coverage.
The second step is to ensure 100% coverage of the api. I want to demonstrate that everything visible works (the api tests pass) and nothing is visible that should not be (the tests demonstrate 100% method invocation).
If the tests fail it should be because not enough is visible in the obfuscated jar (they passed against non-obfuscated code). If the tests pass but get less than 100% coverage - too much is visible in the jar.
Even if you don't adopt this idea, I'd be interested in your thoughts on it.
I am rather confused by this. It sounds like you do not expect EMMA to figure out which classes are obfuscated and which are not, because you will provide an appropriate instrumentation filter ("instrumented with a filter to only pick up only the non-obfuscated classes").
Since you can do this with the current version, what new EMMA functionality is needed?