HI Mirko,
I'm not sure whether I fully understand the scenarios, but I can clarify
some principles of JaCoCo core:
SESSION ID
The session id is an informative identifier which is written with every
execution data dump (along with the time stamp). The session id can be
set with the agent parameter "sessionid". Otherwise it is generated in
the form <hostname>-<randomnumber>. The session id is not evaluated by
the JaCoCo core and is not used for code coverage analysis at all. It is
just reported in the XML and HTML report.
CLASS ID
The class id is the unique identifier for class files. It a 64bit number
calculated with CRC64 from the raw class definition. Every instrumented
class reports its execution data with its class id to the JaCoCo
runtime. The JaCoCo runtime then write exec files with these class ids.
At analysis time (e.g. for report generation or checks) a set of class
files have to be suppiled which define the scope of the report. For
every provided class its class id is calculated (again CRC64) and its
internal structure is fully analyzed (lines, branches etc).
At instrumentation time as well as at analysis time a deterministic
graph algorithm is used to insert probes at the certain position. From
the execution status of these probes all instruction and branch coverage
information can be derived. The probes of every class is a plain boolean
array without any additional information. To ensure the probes actually
inserted at runtime and the probe positions assumed at analysis time are
exactly the same, the exact same class files must be used. E.g. a class
file with different method ordering would screw-up the analysis.
Therefore with the CRC64 class id we ensure that execution data and
analyzed class files match. The problem is that the slightest
modification of the class files will break the CRC64 hash, e.g.
different compiler settings will result in different class ids.
A advantage of class ids is that we can distinguish execution data of
different versions of a class which are executed within the same VM.
SOURCE FILES
Source files are not considered for code caverage analysis at all. The
are not processed by JaCoCo core. Only the HTML report generator may
read source files and provides a pure line number based highlighting.
Syntax higlighting of the Java sources is rendered pure clientside with
JavaScript (with Google Code Prettify).
Best regards,
-marc
On 24.01.14 21:29, Mirko Friedenhagen wrote:
Hello,
I am still a bit confused by the way JaCoCo detects which class files
correspond to which source files.
Given I have a multi-module reactor project where testA has moduleA as
dependency
root/
moduleA
testA
When I execute the tests in testA all classes from moduleA show up in
jacoco.exec as well as the classes of maven-surefire-plugin and junit,
e.g.
Now when I add the source folder from moduleA via
buildhelper-maven-plugin to the sources of testA I have two different
outcomes:
- When I attach the sources in the standard phase (generate-sources)
as one would expect the maven-compiler-plugin compiles the sources of
moduleA again, class files are beneath testA/target/classes and
coverage for all classes is reported.
- When I attach the sources in another phase (say prepare-package) the
maven-compiler-plugin does not compile the sources again, however the
report now is completely empty.
The class files of moduleA are included during the reactor run by
adding moduleA/target/classes to the classpath of testA, the sources
of moduleA are not modified, nonetheless JaCoCo is not able to deduce
that the class files are valid.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
--
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/groups/opt_out.
