We are using emma for finding out the code coverage by the Junit test cases. We could successfully instrument, execute, merge and generate the report.
But the we got some warning during report generation saying
no sources will be embedded in the report.
the following in the ANT task we used to generate the report and the warning during report generation
[emma.merge] processing input files ...
[emma.merge] 2 file(s) read and merged in 391 ms
[emma.merge] merged/compacted data written to [F:\gwscanada\coverage_final.es] {in 313 ms}
[emma.report] 1 file(s) read and merged in 219 ms
[emma.report] not all instrumented classes were compiled with source file
[emma.report] debug data: no sources will be embedded in the report.
[emma.report] writing [txt] report to [f:\gwscanada\report\coverage.txt] ...
[emma.report] not all instrumented classes were compiled with source file
[emma.report] debug data: no sources will be embedded in the report.
[emma.report] writing [html] report to [f:\gwscanada\report\coverage.html] ...
Has anybody idea what we are doing wrong here
Cheers,
Hari
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, then it must be that you are asking EMMA to do coverage not only on your application classes but also on your library dependencies (in "gws.path", perhaps?) and some of them don't have the debug info compiled in.
It would help if I could see how your <instr> task is run, but I am guessing you need to add a filter to it to just instrument the classes you are compiling:
The following are sequence of steps that we are doing
1.gws.src is our source folder. It contains all java files in gws.src/com/frk/canada/gws/* folders
2. gws.path is the classpath (that contains all library dependencies). We are using this path and using javac task for compilation of the code. This task creates class files for com.frk.canada.gws.* and puts in gws.tmp folder.It generates classes in com/frk/canada/gws/* folder structure
3. Then we are executing the instr task on gws.tmp folder that will have only com.frk.canada.gws.* classes.Please note that we are using the overwrite mode here so that the instrumented code overwrites the compiled class files in the same folders
4. While generating the reports we are referering gws.src as sourcepath.
Appreciate if you could let us know whether we are missing some thing here
Cheers,
Hari
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your setup looks correct to me and this is weird because nobody else has reported a problem like this. The only remaining possibility is the fact that one of your *.em or *.es files contains old entries from when your build did not use debug="true" (or a genuine bug in EMMA, of course).
Try this:
- remove *all* EMMA dump files (*.es, *.ec, *.em) and try again
If this does not help I apologize and I will have to release a build update that actually shows examples of classes that lack full debug info to allow cases like this one to be tracked down.
We tried doing a clean build after removing all EMMA dump files. But unfortunately it could not help us in viewing the code coverage.
Meanwhile, we could not find any link to attach the files in the tracker link you have mentioned above. Appreciate if you could help us in this regard.
Awaiting your reply
Cheers,
Hari
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we have an overly complicated build (imagine that ;) ; and i wasn't *positive* that we used debug=on for *every* class.
so, i created a few test cases.
this may be expected behavior, but i found that EACH and EVERY class which is instrumented, MUST be compiled with debug=on, in order to get any line coverage. is this correct?
i still have the tests, if you would like to see them.
thank you for your assistance.
best regards,
scott
<testcases>
src/a/A1.java,A2.java (compiled with debug=on)
b/B1.java,B2.java (compiled with debug=off)
Test1:
A.jar (package a) instrumented
B.jar (package b) not - instrumented
Run A.jar.and B.jar
Result:
Line coverage available for package a.
Test2:
A.jar (package a) instrumented
B.jar (package b) instrumented
Run A.jar.and B.jar
Result:
No line coverage available.
Test3:
A.jar (package a & package b) instrumented
Run A.jar
Result:
No line coverage available.
</testcases>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>this may be expected behavior, but i found that EACH and EVERY class which is instrumented, MUST be compiled with debug=on, in order to get any line coverage. is this correct?
Absolutely! This may appear to be too draconian, but it's actually quite logical if you think about it. If a class has no debug data, line coverage for it can't be computed, end of story.
EMMA is based on bytecode instrumentation, meaning it uses your .class files as input. The only way to map .class to source lines is via what's known as LineNumberTable attribute. It is NOT generated unless you use -g javac option (which includes -g:lines and -g:source which is what EMMA needs). Unfortunately, this is the default javac setting.
Now, even if a single class in the entire instrumentation set is without the line debug info EMMA gives up and refuses to compute line coverage. Why? Because there is no clear way to roll up line coverage (how is EMMA to report to overall line coverage if some classes don't have any line data?).
Scott, I hope this explains your case (I am still puzzled about Hari's and am hoping to release an update soon that should help track this down). There are several options for dealing with this:
(a) just make sure you use -g everywhere. I am kind of surprised this is difficult for you (find every case of <javac> and make sure it says debug="true" ?). Some people don't want to compile with debug info because they think it either slows down their execution or it makes decompilation easier. Both premises are quite false. For all I know, they only disadvantage of always doing -g is your .class files will be larger.
(b) If -g is not possible for whatever reason, well, you can always use block coverage as a substitute for line coverage. Block coverage is always available. I personally think block coverage is a much better metric (see EMMA FAQ http://emma.sourceforge.net/faq.html for my arguments). This may be difficult because it might be a paradigm shift for some or maybe because your manager doesn't get it :)
Well, if neither (a) nor (b) are feasible, the only solution I can offer is to filter out those classes that are compiled without -g (if it has to be that way). I am open to suggestions here, if you think there is another approach.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you follow this link, do you not see a text box for adding a comment and another one for attaching a file (the latter one towards the bottom of the page)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks, for the detailed response. i think i found all of the javac tasks, and they were using a ${compile.debug}; which i then passed in at the command line.
i still don't have line coverage, but i am going to use a filter for the instrumentation. which, really, i should have been doing from the start.
your reasons for the restriction are valid.
does emma have any way of telling what classes were not compiled with -debug?
this would be very helpful.
best regards,
scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also experienced problems with the line coverage. I'm using a Linux system with a blackdown jdk j2sdk-1.4.2-rc1-linux-i586-gcc3.2. When I have my ant build set to build.compiler=modern I'm getting the message that not all instrumented classes have debug data. If I'm setting it to build.compiler=jikes everything is fine. Unfortunately I didn't try sun's compiler.
Anyway I have another problem. As we are using a byte code enhancer shipping with our database persistent objects are enhanced after compilation. Then emma's instrumentation is taking place before the junit task on the already enhanced class files. Again emma is complaining that there is no debug info although I can debug the enhanced classes. Moreover emma is also reporting on the methods the enhancer added which is lowering the total score of a java file - enhanced classes can never reach 100% although they are nicely tested. Somehow JDepend and clover seem to detect such enhancements and don't report on them... so there must be a trick.
regards
/olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When writing my previous message an idea occured to me. I tried it and it works! I simply just instrument the classes before the byte code enhancer is running.
Well, but I can imagine situations where it would be useful to check the coverage of the methods added by byte code enhancement. For example aspects added with aspectJ. Is there any experience on this subject?
thanks
/olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am also seeing an issue here. I am running the JDK 1.4.1_04. The code gets compiled with debug="true" and the debug level explicitly set to "lines, vars, source". I still get the error.
I was wondering if it is possible to have a mix, so if debug information exists for an instrumented file and the source can be found, line reports can be generated, otherwise block is the best it can do. It's frustrating if you have lots of files and only one seems to be missing its code then all reporting stops.
Also, as a workaround, is there a debug flag I can set to help me pinpoint which file is missing either the source code or the debug info?
Thanks,
Sean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I am getting convinced there is a real issue here since it's being reported for 1.4.1 compilers as well. I am planning to release a build update this weekend (have a cable modem going in the new house and I can sit on the floor while working with the "official" build desktop for the time being :) that should log the first class that appears to not have the debug info in it. Unfortunately, the current build does not log this.
What will help me immensely if someone could either attach (to this feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900\) or email to my SF alias (if there are privacy concerns) a zip file containing your .classes that reproduce this problem. Better yet, if you could reproduce the issue in a standalone testcase that would be great.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe I should have written this more clearly. I solved my problem with the missing debug info by switching to another compiler. In my case the latest jikes, an open source java compiler, works fine with EMMA. http://www-124.ibm.com/developerworks/oss/jikes/
/olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am glad you've got it sorted. Believe me, logging files not compiled with -debug was on my release cleanup list, but I had to cut some features in order to release something before going into a period of time of not being able to work on the tool (the several times mentioned closing and moving into a new house).
There is already a feature request for this in the tracker (http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900), although I have not been planning on listing ALL such files by default but perhaps capping the count at some max value (possibly on a per-package level).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hari and others still having this issue should try build 4120. It logs the actual files without full debug info (one sample class per Java package per instrumentation run during instrumentation and up to 3 sample classes per Java package per report generation during reporting).
I hope this will help debug either your build(s) or EMMA, as the case might be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are very happy to inform you that we have found out the files without full debug info using 4120 build.
Actually we are using <rmic> ANT task on only two class files. The stubs and skeletons created by this task does not have the full debug info and 4120 gave us the details about the same. We are not sure at this point of time what may be the problem due to these files. The following are the ant tasks we are using
I am glad you've got it sorted. I should have had a clue about RMI stub/skeleton classes sooner. As soon as you mentioned them, I remembered another common case here at Trilogy: EJB stub classes created by EJB deployer tools (e.g., in Websphere).
Such classes are usually easily excluded using an appropriate instrumentation <filter> (or you could use a separate rmic -d output dir just for RMI stuff, a dir that is not subject to EMMA instrumentation). Furthermore, it is usually the right thing to do, because these wrapper classes don't correspond to any source code written by your team.
For example, in rmic case the debug (-g) option does add some debug info (the LineNumberTable), but it corresponds to auto-generated sources. Usually they are deleted as soon as the stubs are compiled but you can see them if you give -keep option to rmic. It's not the kind of code that needs to be covered at all.
(In fact, EMMA could have easily handled RMI stub/skeleton classes anyway, but rmic does not seem to bother including the SourceFile attribute in them.)
Hi,
We are using emma for finding out the code coverage by the Junit test cases. We could successfully instrument, execute, merge and generate the report.
But the we got some warning during report generation saying
no sources will be embedded in the report.
the following in the ANT task we used to generate the report and the warning during report generation
<emma enabled="${emma.enabled}" >
<merge outfile="${gws.home}/coverage_final.es" >
<fileset dir="${gws.build}">
<include name="*.em" />
</fileset>
<fileset dir="${dynamo.home}">
<include name="*.ec" />
</fileset>
</merge>
<report sourcepath="${gws.src}" >
<fileset dir="${gws.home}" >
<include name="*.es" />
</fileset>
<txt outfile="${gws.home}/report/coverage.txt" />
<html outfile="${gws.home}/report/coverage.html" />
</report>
</emma>
[emma.merge] processing input files ...
[emma.merge] 2 file(s) read and merged in 391 ms
[emma.merge] merged/compacted data written to [F:\gwscanada\coverage_final.es] {in 313 ms}
[emma.report] 1 file(s) read and merged in 219 ms
[emma.report] not all instrumented classes were compiled with source file
[emma.report] debug data: no sources will be embedded in the report.
[emma.report] writing [txt] report to [f:\gwscanada\report\coverage.txt] ...
[emma.report] not all instrumented classes were compiled with source file
[emma.report] debug data: no sources will be embedded in the report.
[emma.report] writing [html] report to [f:\gwscanada\report\coverage.html] ...
Has anybody idea what we are doing wrong here
Cheers,
Hari
Hari,
You need to enable debug info when compiling your Java sources (/g javac option or debug="true" attribute for ANT's <javac> task).
Hi Vladimir,
We have done the build with debug on option itself. find our javac task below
<javac srcdir="${gws.src}" destdir="${gws.tmp}" classpathref="gws.path" includeAntRuntime="no" includeJavaRuntime="no" debug="true" memoryInitialSize="64m" memoryMaximumSize="256m" target="1.3" fork="yes">
<include name="com/frk/canada/gws/**/*.java"/>
</javac>
Please let us know whether we are missing anything else
Cheers,
Hari
Ok, then it must be that you are asking EMMA to do coverage not only on your application classes but also on your library dependencies (in "gws.path", perhaps?) and some of them don't have the debug info compiled in.
It would help if I could see how your <instr> task is run, but I am guessing you need to add a filter to it to just instrument the classes you are compiling:
<emma>
<instr ...>
<filter includes="com.frk.canada.gws.*" />
...
</instr>
</emma>
Hi Vladimir,
First of all thank you very much for your prompt replies
The following is the ANT task we have used for instrumentation
<emma enabled="${emma.enabled}" >
<instr instrpath="${gws.tmp}" mode="overwrite"/>
</emma>
The following are sequence of steps that we are doing
1.gws.src is our source folder. It contains all java files in gws.src/com/frk/canada/gws/* folders
2. gws.path is the classpath (that contains all library dependencies). We are using this path and using javac task for compilation of the code. This task creates class files for com.frk.canada.gws.* and puts in gws.tmp folder.It generates classes in com/frk/canada/gws/* folder structure
3. Then we are executing the instr task on gws.tmp folder that will have only com.frk.canada.gws.* classes.Please note that we are using the overwrite mode here so that the instrumented code overwrites the compiled class files in the same folders
4. While generating the reports we are referering gws.src as sourcepath.
Appreciate if you could let us know whether we are missing some thing here
Cheers,
Hari
Hari,
Your setup looks correct to me and this is weird because nobody else has reported a problem like this. The only remaining possibility is the fact that one of your *.em or *.es files contains old entries from when your build did not use debug="true" (or a genuine bug in EMMA, of course).
Try this:
- remove *all* EMMA dump files (*.es, *.ec, *.em) and try again
If this does not help I apologize and I will have to release a build update that actually shows examples of classes that lack full debug info to allow cases like this one to be tracked down.
Meanwhile, it would help me if you could add "-debug" to your ANT invocation that includes source compilation, zip the resulting ANT output in a file, and attach to an update to the following tracker issue: http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900
Hi Vladimir,
We have done a complete build with all emma dump files removed. But unfortunately it could not help us in viewing the code coverage.
We could not see any option to attach the files in the tracker link mentoned above. Appreciate if you could help us in doing this.
Awaiting your earliest reply
Cheers,
Hari
Hi Vladimir,
We tried doing a clean build after removing all EMMA dump files. But unfortunately it could not help us in viewing the code coverage.
Meanwhile, we could not find any link to attach the files in the tracker link you have mentioned above. Appreciate if you could help us in this regard.
Awaiting your reply
Cheers,
Hari
vlad,
i am seeing the same problem, and am unable to view the line coverage.
i am using sun's j2se 1.5 b51.
i am compiling with debug=true, also.
best regards,
scott
<patternset id="netui.server.jars.patternset">
<include name="**/netui-compilerx.jar"/>
<include name="**/netui-pageflow.jar"/>
<include name="**/netui-scoping.jar"/>
<include name="**/netui-tags-databinding.jar"/>
<include name="**/netui-tags-datagrid.jar"/>
<include name="**/netui-tags-html.jar"/>
<include name="**/netui-tags-template.jar"/>
<include name="**/netui-util.jar"/>
<include name="**/netui-wl.jar"/>
</patternset>
...
<emma enabled="true"
<instr instrpathref="${emma.instr.path.refid}" mode="fullcopy" metadatafile="${emma.coverage.em}"
destdir="${run-instr.destdir}"/>
</emma>
...
<emma enabled="${emma.enabled}" >
<report>
<infileset dir="${emma.coverage.dir}">
<include name="**/coverage.em"/>
<include name="**/coverage.ec"/>
</infileset>
<sourcepath>
<dirset id="netui.server.src.dirset" dir="${netui.server.src.dir}">
<include name="actionview"/>
<include name="codegen"/>
<include name="codegen-schema"/>
<include name="common"/>
<include name="commonui"/>
<include name="docmodel"/>
<include name="document"/>
<include name="flowview"/>
<include name="introspectorx"/>
<include name="jspdesigner"/>
<include name="model"/>
<include name="netuigen"/>
</dirset>
<dirset id="netui.ide.src.dirset" dir="${netui.ide.src.dir}">
<include name="async"/>
<include name="bootstrap"/>
<include name="compiler"/>
<include name="compilerx"/>
<include name="javascript"/>
<include name="pageflow"/>
<include name="scoping"/>
<include name="tags-databinding"/>
<include name="tags-datagrid"/>
<include name="tags-html"/>
<include name="tags-template"/>
<include name="tomcat-common"/>
<include name="tomcat-server"/>
<include name="tomcat-webapp"/>
<include name="util"/>
<include name="webapp-template"/>
<include name="weblogic"/>
<include name="xdoclet-compiler"/>
</dirset>
</sourcepath>
<xml outfile="${emma.coverage.reports.dir}/coverage.xml"
depth="package"
/>
<html outfile="${emma.coverage.reports.dir}/coverage.html"
sort="+package,+name"
depth="method"
columns="name,class,method,block,line"
/>
</report>
</emma>
#compile options
compile.debug=true
compile.deprecation=off
compile.optimize=off
compile.source=1.4
compile.source.1.5=1.5
vlad,
we have an overly complicated build (imagine that ;) ; and i wasn't *positive* that we used debug=on for *every* class.
so, i created a few test cases.
this may be expected behavior, but i found that EACH and EVERY class which is instrumented, MUST be compiled with debug=on, in order to get any line coverage. is this correct?
i still have the tests, if you would like to see them.
thank you for your assistance.
best regards,
scott
<testcases>
src/a/A1.java,A2.java (compiled with debug=on)
b/B1.java,B2.java (compiled with debug=off)
Test1:
A.jar (package a) instrumented
B.jar (package b) not - instrumented
Run A.jar.and B.jar
Result:
Line coverage available for package a.
Test2:
A.jar (package a) instrumented
B.jar (package b) instrumented
Run A.jar.and B.jar
Result:
No line coverage available.
Test3:
A.jar (package a & package b) instrumented
Run A.jar
Result:
No line coverage available.
</testcases>
>this may be expected behavior, but i found that EACH and EVERY class which is instrumented, MUST be compiled with debug=on, in order to get any line coverage. is this correct?
Absolutely! This may appear to be too draconian, but it's actually quite logical if you think about it. If a class has no debug data, line coverage for it can't be computed, end of story.
EMMA is based on bytecode instrumentation, meaning it uses your .class files as input. The only way to map .class to source lines is via what's known as LineNumberTable attribute. It is NOT generated unless you use -g javac option (which includes -g:lines and -g:source which is what EMMA needs). Unfortunately, this is the default javac setting.
Now, even if a single class in the entire instrumentation set is without the line debug info EMMA gives up and refuses to compute line coverage. Why? Because there is no clear way to roll up line coverage (how is EMMA to report to overall line coverage if some classes don't have any line data?).
Scott, I hope this explains your case (I am still puzzled about Hari's and am hoping to release an update soon that should help track this down). There are several options for dealing with this:
(a) just make sure you use -g everywhere. I am kind of surprised this is difficult for you (find every case of <javac> and make sure it says debug="true" ?). Some people don't want to compile with debug info because they think it either slows down their execution or it makes decompilation easier. Both premises are quite false. For all I know, they only disadvantage of always doing -g is your .class files will be larger.
(b) If -g is not possible for whatever reason, well, you can always use block coverage as a substitute for line coverage. Block coverage is always available. I personally think block coverage is a much better metric (see EMMA FAQ http://emma.sourceforge.net/faq.html for my arguments). This may be difficult because it might be a paradigm shift for some or maybe because your manager doesn't get it :)
Well, if neither (a) nor (b) are feasible, the only solution I can offer is to filter out those classes that are compiled without -g (if it has to be that way). I am open to suggestions here, if you think there is another approach.
Hi Vladimir,
As requested earlier, appreciate if you could help us in attaching the files to the tracker
http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900
Cheers,
Hari
Hari,
When you follow this link, do you not see a text box for adding a comment and another one for attaching a file (the latter one towards the bottom of the page)?
vlad,
thanks, for the detailed response. i think i found all of the javac tasks, and they were using a ${compile.debug}; which i then passed in at the command line.
i still don't have line coverage, but i am going to use a filter for the instrumentation. which, really, i should have been doing from the start.
your reasons for the restriction are valid.
does emma have any way of telling what classes were not compiled with -debug?
this would be very helpful.
best regards,
scott
First of all congratulations for this great tool.
I also experienced problems with the line coverage. I'm using a Linux system with a blackdown jdk j2sdk-1.4.2-rc1-linux-i586-gcc3.2. When I have my ant build set to build.compiler=modern I'm getting the message that not all instrumented classes have debug data. If I'm setting it to build.compiler=jikes everything is fine. Unfortunately I didn't try sun's compiler.
Anyway I have another problem. As we are using a byte code enhancer shipping with our database persistent objects are enhanced after compilation. Then emma's instrumentation is taking place before the junit task on the already enhanced class files. Again emma is complaining that there is no debug info although I can debug the enhanced classes. Moreover emma is also reporting on the methods the enhancer added which is lowering the total score of a java file - enhanced classes can never reach 100% although they are nicely tested. Somehow JDepend and clover seem to detect such enhancements and don't report on them... so there must be a trick.
regards
/olaf
When writing my previous message an idea occured to me. I tried it and it works! I simply just instrument the classes before the byte code enhancer is running.
Well, but I can imagine situations where it would be useful to check the coverage of the methods added by byte code enhancement. For example aspects added with aspectJ. Is there any experience on this subject?
thanks
/olaf
I am also seeing an issue here. I am running the JDK 1.4.1_04. The code gets compiled with debug="true" and the debug level explicitly set to "lines, vars, source". I still get the error.
I was wondering if it is possible to have a mix, so if debug information exists for an instrumented file and the source can be found, line reports can be generated, otherwise block is the best it can do. It's frustrating if you have lots of files and only one seems to be missing its code then all reporting stops.
Also, as a workaround, is there a debug flag I can set to help me pinpoint which file is missing either the source code or the debug info?
Thanks,
Sean
Ok, I am getting convinced there is a real issue here since it's being reported for 1.4.1 compilers as well. I am planning to release a build update this weekend (have a cable modem going in the new house and I can sit on the floor while working with the "official" build desktop for the time being :) that should log the first class that appears to not have the debug info in it. Unfortunately, the current build does not log this.
What will help me immensely if someone could either attach (to this feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900\) or email to my SF alias (if there are privacy concerns) a zip file containing your .classes that reproduce this problem. Better yet, if you could reproduce the issue in a standalone testcase that would be great.
Maybe I should have written this more clearly. I solved my problem with the missing debug info by switching to another compiler. In my case the latest jikes, an open source java compiler, works fine with EMMA. http://www-124.ibm.com/developerworks/oss/jikes/
/olaf
vlad,
i got everything working for me. we were also using our custom compiler (and not passing in -debug).
the source code linking is awesome, and is very valuable when talking to developers/testers about outages.
another one of our teams is probably going to use your tool; instead of one that rhymes with 'over'.
;)
<FEATURE_REQUEST>
-showNoDebug
output the list of ALL the files which were NOT compiled with -debug.
This would be VERY helpful. It was a painful process for me to track these down.
</FEATURE_REQUEST>
thanks,
scott
Scott,
I am glad you've got it sorted. Believe me, logging files not compiled with -debug was on my release cleanup list, but I had to cut some features in order to release something before going into a period of time of not being able to work on the tool (the several times mentioned closing and moving into a new house).
There is already a feature request for this in the tracker (http://sourceforge.net/tracker/index.php?func=detail&aid=971176&group_id=108932&atid=651900), although I have not been planning on listing ALL such files by default but perhaps capping the count at some max value (possibly on a per-package level).
Hari and others still having this issue should try build 4120. It logs the actual files without full debug info (one sample class per Java package per instrumentation run during instrumentation and up to 3 sample classes per Java package per report generation during reporting).
I hope this will help debug either your build(s) or EMMA, as the case might be.
Hi Vladimir,
First of all we appreciate your effort in releasing the minor build to debug this issue
We are also working on 4120 build with our source code and will get back to you in case of issues
Cheers,
Hari
Hi Vladimir,
We are very happy to inform you that we have found out the files without full debug info using 4120 build.
Actually we are using <rmic> ANT task on only two class files. The stubs and skeletons created by this task does not have the full debug info and 4120 gave us the details about the same. We are not sure at this point of time what may be the problem due to these files. The following are the ant tasks we are using
<rmic base="${gws.tmp}" classname="com.frk.canada.gws.util.ei.GwsEicImpl" classpathref="gws.path" debug="true" includeAntRuntime="no" includeJavaRuntime="no" />
<rmic base="${gws.tmp}" classname="com.frk.canada.gws.user.GWSService" classpathref="gws.path" debug="true" includeAntRuntime="no" includeJavaRuntime="no" />
We are using debug="true" in these taks as well. Any information regarding this issue will be highly appreciated
As of now we have excluded the stubs/skeletons created by these tasks in instrumentation and got the coverage for the entire source code.
Right now we are in the process of promoting this tool for coverage across the organization
Thank you very much again for creating such a wondeful and useful tool
Cheers,
Hari
Hari,
I am glad you've got it sorted. I should have had a clue about RMI stub/skeleton classes sooner. As soon as you mentioned them, I remembered another common case here at Trilogy: EJB stub classes created by EJB deployer tools (e.g., in Websphere).
Such classes are usually easily excluded using an appropriate instrumentation <filter> (or you could use a separate rmic -d output dir just for RMI stuff, a dir that is not subject to EMMA instrumentation). Furthermore, it is usually the right thing to do, because these wrapper classes don't correspond to any source code written by your team.
For example, in rmic case the debug (-g) option does add some debug info (the LineNumberTable), but it corresponds to auto-generated sources. Usually they are deleted as soon as the stubs are compiled but you can see them if you give -keep option to rmic. It's not the kind of code that needs to be covered at all.
(In fact, EMMA could have easily handled RMI stub/skeleton classes anyway, but rmic does not seem to bother including the SourceFile attribute in them.)
This gives me an idea for a new feature: perhaps add an EMMA option that will auto-exclude classes without full debug info just for cases like this one. The idea recorded: http://sourceforge.net/tracker/index.php?func=detail&aid=977525&group_id=108932&atid=651900