Hi Mirko,
why do you think analyzing code coverade for a dependency jar should not
be possible? If this JAR (or the class files within the JAR) are used
also during test execution this should give the same class ids.
JAR files are nothing else than ZIP files, the packed classes do not get
altered. Pack200 is another story... here unfortunately class files
actually are modified.
Cheers,
-marc
On 25.01.14 21:22, Mirko Friedenhagen wrote:
Hello Marc,
I see why the calculation of the CLASS ID will prohibit coverage of
classes coming from a dependency jar. However when the classes were
compiled in the same maven reactor, a reuse should be possible, should
it not?
Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Sat, Jan 25, 2014 at 5:53 PM, Marc R. Hoffmann
<[email protected]> wrote:
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.
--
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.
