jacoco classdumpdir feature gives diffenent count of classes

[maury...@gmail.com]

I have classes bundled into different jar, at IT(integration tests are ) phase, the server ( glassfish server) is started with these jars in classpath and IT are run. I attach jacoco agent to server jvm process which creates a jacoco.exec files.

I am currently using "classdumpdir" to dump the classes in one particular folder and use that folder in report generation. The problem is on each run I get different number of classes in that folder, that changes the coverage value every time? Am I doing something wrong ?

[Marc R. Hoffmann]

Use the original classes from the JAR files to create your report. Note
that JaCoCo can directly read JAR files.

Regards,
-marc

[maury...@gmail.com]

There are different modules of IT and are not structured in parent child setup, in order to get aggregated report & also to avoid complexities arising due to "runtime changes in classes", I thought of using classdumpdir attribute , and aggregating using Jenkins Jacoco plugin.
Is there any reason as to why the class count value changes between runs?

[Evgeny Mandrikov]

On Thursday, July 27, 2017 at 11:30:37 AM UTC+2, maury...@gmail.com wrote:

Is there any reason as to why the class count value  changes between runs?

Only classes that are loaded by JVM are dumped. Number of loaded classes might vary from run to run - there are plenty of reasons: non-determinism in application; different actions performed with application in different runs; etc... And similarly number of loaded classes not necessarily includes all the classes of your application. For these reasons - use the original classes from the JAR files of your application to create your report.

There are different modules of IT and are not structured in parent child setup, in order to get aggregated report &

Don't know what you mean by "parent child setup", but the only requirement for use of JaCoCo Maven Plugin goal "report-aggregate" ( http://www.jacoco.org/jacoco/trunk/doc/report-aggregate-mojo.html ) - is that all modules should be part of the same Maven reactor.

Alternatively there is JaCoCo Ant Task "report" ( http://www.jacoco.org/jacoco/trunk/doc/ant.html ) that provide great flexibility in specification of files for report.

 

also to avoid complexities arising due to "runtime changes in classes"

There is pre-instrumentation aka offline instrumentation ( http://www.jacoco.org/jacoco/trunk/doc/offline.html ) to deal with cases if classes are modified at runtime by other tools.