How to read package annotations from Clover DB

Our company has many teams working on a single project and we wanted to monitor how much code is covered with tests in parts of the project owned by individual teams. We wrote an application that worked on XML reports generated by Clover and calculated per-team code coverage based on code ownership defined in a separate JSON file.

The main disadvantage of this approach is that the file can easily get out of sync as it is located nowhere near the code where developers are making their changes. So we decided we would use package- and class-level annotations to couple the code and its owners.

As the XML reports do not contain information about annotations, we thought we would use the clover.db database instead. We found out that annotations and their attribute values could be read via ClassInfo.getModifiers().getAnnotations() and MethodInfo.getSignature().getAnnotations() for classes and methods, respectively. We were however not able to find out where to get this information for packages. Neither the PackageInfo interface, nor the FullPackageInfo class seemed to contain this kind of information.

We're using Clover version 4.0.2.

Does Clover process package-level annotations and can we read them somehow from the clover.db database?

We are running the test builds on multiple servers in a cloud and then collecting the coverage data to a separate server, where it is processed. If the package-level annotations were already contained in the clover.db and we could read them, it would be much easier for us.

Example of annotations usage

The code below demonstrates how we want to use the code-ownership annotations and what would be the expected ownership of individual classes:

@Owner(team="Team A")
package module;
package module;

public class SomeClass {
    // ...
package module.submodule;

public class AnotherClass {
    // ...
package module;

@Owner(team="Team B")
public class YetAnotherClass {
    // ...
    public static class InnerClass {
        // ...


In our use case, we would expect that:

  • Team A owns SomeClass because it has no Owner annotation, and thus, inherits the owner from the module package. Team A also owns AnotherClass, as it inherits owner from the module.submodule package, which in turn inherits owner from its parent, the module package.
  • Team B owns YetAnotherClass, because they're specified in the Owner annotation of that class, and also the InnerClass as it inherits the owner from AnotherClass.

The @Owner(team="Team A") annotation on the module package is the one that we don't know how to read from Clover DB.

1 answer

1 accepted

0 votes
Answer accepted

Hi Oto!

Thank you for a great question. Unfortunately, Clover does not store annotations from '' files in its database. I have created a feature request for this:

However, it's not on a short-term roadmap and I can't tell whether/when it could be implemented.


As I understand, your requirement is to have code coverage information divided into several categories (related with teams in your case) and you're looking for an efficient way to manage this information.


Your approach to use annotations on a class and method level is quite interesting.


I'd like to share few other ideas with you:

1) You could use version control system to determine ownership of the source file (for instance to see author of the last commit; or a person who did most of the last N commits; etc). Thanks to this, you wouldn't have to maintain a global file with mappings or to put annotations in a source code.

2) Instead of reading the Clover database directly and combining this information from Clover's XML file, you can prepare separate reports (HTML or XML) for each team. Thanks to this you won't have to calculate code coverage manually.

Just use file exclusion patterns in a <clover-report> task. Furthermore, if you declare more than one <current> tag, all HTML reports will be linked with each other (there will be a "Reports" drop down on a blue header).


&lt;clover-report initstring="clover.db"&gt;
    &lt;current outfile="html/teamA"&gt;
        &lt;fileset includesfile="includes-teamA.txt"/&gt;
    &lt;current outfile="html/teamB"&gt;
        &lt;fileset includesfile="includes-teamB.txt"/&gt;

The includes-team*.txt files can be generated (e.g. from a version control system) or maintained manually.


More details here:



Hi Marek, thanks a lot for quick answer and for sharing your ideas. I'm afraid that determining code ownership from version control system won't work very well in our case, because any developer can change any piece of code, so people from the owning team don't have to be authors of all the code in their code area. However, they should have the best knowledge of the area and should always be asked for code review. We will probably make a tool that will process package and class annotations in the JAR files and generate the JSON file we are using now (or the includes files you mention in point 2). The idea of configuring Clover to generate separate reports for individual teams is very interesting. I didn't know about this possibility. I will definitely look into it and see if it could simplify our code coverage processing tool. Once again, thanks for your help! Cheers Oto

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Opsgenie

Getting the Most out of Atlassian and Opsgenie Together

We’re excited to invite you to this action-packed webinar where we will demonstrate how to integrate Opsgenie’s powerful alerting and on-call management tools with your entire Atlassian stack. Mar...

66 views 0 1
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you