Hi,
interesting questions. At first classes are analyzed separately, one by
one. No matter if the same name or even id. For this the analyzer uses a
simple output API:
public interface ICoverageVisitor {
/**
* For analyzed class coverage data is emitted to this method.
*
* @param coverage
* coverage data for a class
*/
public void visitCoverage(IClassCoverage coverage);
}
If the report would consist of a plain list of class files this would be
definitely sufficient.
For the coverage report a set of classes is combined in a so called
bunde using the CoverageBuilder to get line coverage and total numbers
on different levels. Here we would have two issues with multiple
versions fo the same class:
1) Source Annotation
What the bundle builder does is to create nodes for source files used
for the source highlighting. Here multiple classes can contribute to the
source highlighting (secondary classes, inner classes). The instruction
and branch counters are summarized for every line from the different
class files. If we would combine mutliple versions of the same class
into the same source, counters in a particular line might double,
coverage information might get inaccurate (or not understandable for the
user) if only one version of the class was executed.
2) Total Numbers
Counters are summarized on package and bundle level. If we would simply
sum-up the counter values of all versions of a class I'm not quite sure
whether this is what the users expect.
Best regards,
-marc
On 17.10.14 09:15, [email protected] wrote:
Hi,
Why generate coverage report by class name.
As we know, there is class id in ExecutionData, and could calculate class id
from class , so why not use class id?
--
You received this message because you are subscribed to the Google Groups "JaCoCo
and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
