Instrumented jars

[Sanix]

I'm trying to create instrumented jars using gradle (which atlassian is still not supporting btw...). I was able to create a jar containing the instrumented classes. I added the jar as a dependency to my project X and run clover. Unfortunately only the classes of project X will show in the report. The instrumented classes from the jar are completely ignored.

Do I need this clover.db (registry) file somewhere, that this will work? If yes, how to I package it with the jar?

[Sanix]

Ok, thanks again for your answer.

Yes, I've been compiling one module after another. Now with an absolute path this works quite well and I get a single clover.db file (I remove the jar suffix). Even the speed is acceptable (generating the instrumented classes using one db file).

Now the thing with xyz-db.test and xyz-db.jar is not true anymore, since I use the same init string for everything making my life much easier. What I noticed is a massive drop in speed if all the tests using the instrumented jar write to the same db. Is this correct or must it be another issue?

Before I compiled classes for each module and executed the tests and afterwards merged all the resulting db files together. This I don't have to do anymore, which is much simpler but also much slower.

[Marek Parfianowicz]

> What I noticed is a massive drop in speed if all the tests using the instrumented jar write to the same db. Is this correct or must it be another issue? Not necessarily. How much modules / clover.db updates do you have? I've seen performance problems in projects running ~ 500 Clover's coverage recorders (such number of recorders can be related with having 500 clover.db updates or compiling 500 separate modules) and running ~1000 tests. As a result ~0.5 million of coverage files were produced. Such problems were mainly related with Grails-based projects. And for this reason a dedicated coverage recorder has been created ("shared") - see https://confluence.atlassian.com/display/CLOVER/Coverage+Recorders for more details. How much coverage recording files do you see in your project? Where do you notice that massive drop in speed exactly - the whole application is running slower, tests are slower, there are delays between testing and generation of Clover's reports? I'm asking, because in case you use an "interval" or "threaded" flush policy, then the <clover-report> task pauses for '2 * flushinterval' before creating a report. In case of high values of flushinterval and in case when reports are being generated for every module separately, this may be perceived as a slowdown.

[Marek Parfianowicz]

> What I noticed is a massive drop in speed if all the tests using the instrumented jar write to the same db. Is this correct or must it be another issue? Would you be able to run a profiler on your application?

[Marek Parfianowicz]

With the absolute version I managed to generate several instrumented jars, which have correct dependencies to each other and one clover.db-jar file

Do you mean that you have been compiling one module after another, using the same clover.db-jar file for each module? I'm asking because I just want to know how many databases do you have. Using the same clover.db for several modules is quite OK, by the way.

Some with -testXYZ and some with -jarXYZ (recording files according to your documentation).

Yes, files named like "<clover.db><some_hash_code>" are coverage recording files. They contain information about number of hit counts for every code element and they are being created when application is running.

These clover.db-jartypahl_i3pzrdw2 files will be directly created by the instrumented classes? So the initially set init string matters here?

These coverage recording files are being created by instrumented classes when an application is running. They are being written to the same directory where the Clover database is located. So yes, the initstring matters here - either the one used during compilation or the one used at runtime (-Dclover.initstring, -Dclover.initstring.basedir, ...).

Are they any need for me or will they be automatically merged together to some clover.db file, so I only need to merge 2 db files

When merging databases you have to list input Clover databases (clover.db-jar and clover.db-test in your case). Clover will search for corresponding coverage recording files. Which means that you have to ensure that these coverage recording files are available at the time of merge. They usually are, unless your build is scattered. For instance: if you have separate plans for compilation, tests and reporting and you are passing Clover databases as artifacts between plans, you have to pass coverage recordings as well (for db merge & report generation).

The merged database clover.db-test only contains the recordings from the small project but not from the instrumented jars. 

I thought that the clover.db-test contains data for your unit tests. But you wrote that this is a merged database. Which one is true?

This could also be a plugin issue.

If you think that this is a plugin issue, then I suggest trying out a command line tool:

https://confluence.atlassian.com/display/CLOVER/CloverMerge

if it produces the same result.

[Sanix]

Thanks for your answer. Our setup is quite complex actually.

We have a multi-module project which will generate several jars (these ones I want to have instrumented). I first tried the relative approach which killed me. With the absolute version I managed to generate several instrumented jars, which have correct dependencies to each other and one clover.db-jar file.

Now, we have several small projects executing some tests. These tests should use the instrumented jars. This works so far that the jars are correctly downloaded. I also use the absolute initString path here.The code of this project will also be instrumented and creates a clover.db-test file. Now when I start executing the tests, I see several files being creaed. Some with -testXYZ and some with -jarXYZ (recording files according to your documentation).

The merged database clover.db-test only contains the recordings from the small project but not from the instrumented jars. This could also be a plugin issue.

Still there are some things which are not very clear to me. These clover.db-jartypahl_i3pzrdw2 files will be directly created by the instrumented classes? So the initially set init string matters here? Are they any need for me or will they be automatically merged together to some clover.db file, so I only need to merge 2 db files (one from the instrumented jars and one from the tests projects)?

[Marek Parfianowicz]

If I understood you correctly, you're building two projects with Clover and thus creating also two clover.db files. Am I right? If yes, then in such case:

1) Classes from both projects instrumented by Clover must be able to read the clover.db file (from their corresponding project). If clover.db is not found then no code coverage is recorded (you can find warnings about it in test logs).

Are you building and testing both projects on the same machine?

If yes, then the easiest way is to use an absolute path for the 'initstring' - as path to a database will be stored in instrumented classes.

If not, then you have to

a) use relative path and different database names in 'initstring' (e.g. 'clover1.db' + 'clover2.db'),

b) copy clover.db files to a test machine and

c) use the -Dclover.initstring.basedir property for test run in order to point to new location of databases.

2) You have to merge two databases after execution of tests. You can use the <clover-merge> task, for instance.

3) You have to generate Clover reports using the merged database.

See also:

https://confluence.atlassian.com/display/CLOVER/JVM+properties

https://confluence.atlassian.com/display/CLOVER/Using+Clover+in+various+environment+configurations

[Marek Parfianowicz]

PS: > If yes, how to I package it with the jar? Please don't package clover.db inside a JAR file.