Marc, I have put together a small sample project at https://github.com/mfriedenhagen/pastebin/tree/jacoco-with-sources-from-dependent-jars (please checkout the jacoco-with-sources-from-dependent-jars branch).
* module test is using one class from module app. * I attached the source path of app (part of the reactor) and junit (by adding the sources jar) via the buildhelper-maven-plugin. * When I do choose the standard phase for buildhelper-maven-plugin:add-source (generate-sources) I see both the coverage for app as well as for the junit classes because all classes are compiled again during the compile phase. * When I do choose a later phase for buildhelper-maven-plugin:add-source (prepare-package) the used classes should be taken from the reactor for app and from the junit jar. * While I understand that JaCoCo is not able to use classes from the junit jar, I do not understand why coverage for app/src/main/java/net/friedenhagen/samples/jacocowithsourcesfromdependentjars/App.java is not available. 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 10:31 PM, Marc R. Hoffmann <[email protected]> wrote: > 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. -- 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.
