Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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 'package-info.java' files in its database. I have created a feature request for this:

https://jira.atlassian.com/browse/CLOV-1654

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).

Example:

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

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

 

More details here:

 

Cheers
Marek

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
TAGS
Community showcase
Published in Opsgenie

Investigate deployment-related incidents with Bamboo and Opsgenie together

Back in April of last year one of the major product announcements from Opsgenie was the launch of the Incident investigation view which created a deep connection between Bitbucket and Opsgenie, empow...

104 views 1 4
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you