> Hi Stephen,
> I've been using your plugin for a client's Hudson installation. I
> noticed that
> the Hadoop project uses your plugin too. However, their report
> looks like the "classic" Clover report vs. the one that the plugin
> generates from the XML and presents inside Hudson.
> I noticed the wiki
> (http://hudson.gotdns.com/wiki/display/HUDSON/Clover+Plugin) says:
> The plugin will not extract any information from these reports,
> but will use
> them as a better formatted most recent coverage report when they
> are available.
> I am generating HTML reports from Clover already, but they're not
> magically being picked up by the plugin. How can I get the plugin to
> "use them"?
The big issue I have had with the clover plugin is handling multiple
modules. With a multi-module, unless the build is configured to
produce an aggregated report, there will be multiple clover reports.
The best way to get a coverage report in such circumstances is to
produce an aggregated report.
Most of my projects build using Maven2. Maven2 has good, but not
perfect, support for aggregating clover reports. Some of the issues
are when you have EAR artifacts (due to some internal validation in
the EAR plugin that causes it to fail if there are artifacts with
classifiers and no classifiers specified, and as clover adds an
artifact with a classifier, you cannot run clover on a master pom
which includes an EAR module whithout using profiles and invoking
maven multiple times)
With Ant build scripts, you can, as always, do anything you want, any
way you want, so it is up to the author of the Ant build script to
produce an aggregated report.
In both cases (ANT and Maven2), the plugin assumes that all the
reports are put into the same directory [Clover report directory].
Wildcards do not work, for reasons I will go into later.
If there is a clover.xml in this directory, it will enable trending.
If there is an index.html in this directory, it will use the HTML
reports generated by clover.
If there is no index.html but there is a clover.pdf, then the PDF
report will be used.
With no clover.pdf or index.html but only a clover.xml, then the
plugin will generate the "poor man's" report.
> Also, I'm interested in contributing back some changes.
If you can send me the patches I'll have a look, see if they warrant
an intermediate release before the back-port from Cobertura overwrites
> Are you still actively developing it?
I said above that wildcards do not work. Here is the problem. When
you have multiple modules, ideally you want the coverage tool to
aggregate the results from all of the modules (in order to get the
true branch coverage values).
Problems arise when the build scripts get "smart" and clean up
intermediate files (i.e. the serialized coverage results) and only
leave the reports.
Additional problems arise when multiple modules are built using
separate build scripts (I think in those cases they should be separate
Hudson projects, but let's not go there)
Then there is the fun of different modules using different coverage
tools (for example, one coverage tool for the C++ code while another
for the Java code)
I can see a case where there is a single project that has coverage data from:
* Cobertura (for one java module that has been produced by one group)
* Emma (for a different module that has been produced by another group)
* Clover (for a couple of modules)
* Some C++ coverage tool (for native code called via JNI)
* Some .NET coverage tool (for another module)
[I can feel Peter Reilly wandering over to my cube and telling me
"That's a sick scenario" ;-) ]
What is the code coverage result for this Hudson project?
Don't worry, I have this problem solved! The solution to this (and
also some of the problems I have with my Clover plugin) is held in the
Here is my plan:
1. Get the Cobertura plugin to a 1.0 release (all that remains is:
support for Kohsuke's Maven2-style projects [aside: I hate this style
of project, I thought at the time that it was a mistake. Most of the
issues with Hudson are due to this project type. I get more consistent
Maven2 builds from the Free-Style projects. However, it does seem to
have a lot of fans, so I don't consider the Cobertura plugin to be 1.0
until it has support for that type of project]; and some better
caching of the project level trend graph)
2. Back-port the Cobertura plugin to the Clover plugin (this will
ditch most of the clover code, except for the clover.xml parser) At
this point I fully expect to hear lots of screams from people who like
the Clover HTML reports and are upset that they have been replaced by
the "multi-module aggregating Hudson internal painted source code"
reports. But we will have wildcard support and Maven2-style project
3. Merge the cobertura and clover plugins into the coverage plugin
(actually quite easy as it should only be the parsers). Once this
point is reached, I may kill off the Clover and Cobertura plugins...
or I may keep them... a discussion will be held on the list... One
alternative is to merge the generic coverage code into the core and
leave the parsers in the plugins, another is to have the clover and
cobertura plugins be actually plugins for the coverage plugin.
4. Write a parser for Emma... same issue with regards to the Emma plugin.
5. Write a parser for GCov, and probably whatever commercial C++
coverage tool I can get my hands on.
So to answer your original question, yes I am still actively
developing it... it's just that it needed a massive refactoring and
that refactoring is taking place in the Cobertura plugin and I only
want to do one back-port of those changes.
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]