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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.