RE: Question about Clover Hudson plugin

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

RE: Question about Clover Hudson plugin

Stephen Connolly-2
Quoting Kirk True <[hidden email]>:

> 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  
> ( 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  
Cobertura plugin!

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.

6. Write a parser for NCover (though it's no longer free - if they are  
reading this and want to give me a license, I'll consider writing a  
parser for it! ;-) ), or PartCover ( ) or maybe this: if it's still  

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.

> Thanks,
> Kirk

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view

RE: Question about Clover Hudson plugin

Stephen Connolly-2
Update! ;-)
Peter Reilly wrote
I wouldn't exactly call it a cube!
Stephen Connolly wrote
[I can feel Peter Reilly wandering over to my cube and telling me  
"That's a sick scenario" ;-) ]