Adding the Cobertura Merge task

I'm interested!

The merge task should take 2 forms.

1) Ability to merge any arbitrary cobertura.ser files together. As specified by the configuration (consider using includes/excludes with the plexus DirectoryScanner)

2) Multi-Module merge. Similar in functionality to the javadoc and clover multi-module reports, where all of the reports from the sub modules are rolled up into a giant master report.

I've sadly been out of commission for the last month or so, which is why progress on this bit seems to have stalled. I'm back on it, however, and hope to make some progress very soon.

On that note, is there any place to get help, other than the large, all-encompassing Mojo and Maven mailing lists? I've found questions and problems to be popping up at an alarming rate, and not having to spend the better half of a day scouring (extremely scarce) documentation and ancient mailing list archives to solve each and every one of them would really speed things up.

Now, onto the feedback presented.

1) I assume that by "arbitrary" you mean "any two or more .ser files within a projects submodules"? This would then enable the generating of a super-report, covering a subset of the project's submodules, as set up in the config file. Am I correct in my assumption?

2) This is what I originally intended, and what my employer wants. I'll probably concentrate my efforts on this, adding support for 1) as I feel "on top" (which is far off, admittedly).

Well, the merge task itself has been written - and wasn't very hard to do.

However, the MergeMojo is giving me grief. My initial idea was to attach to a phase in the lifecycle so that it merges automatically whenever a build is done. This poses two issues, one of which could possibly be a stopper for this approach.

First of all, I can't attach it to any phase, neither with the @execute phase clause, the @phase clause or inside of lifecycle.xml. I guess I'm missing something Maven-technical here, but I can't figure it out. It outputs when run as mvn cobertura:merge on the command line, but it's never a part of any build cycle, neither the regular one or the site one.

Second, it would seem that the top-level project gets processed before all the modules, which is no good. Unless there is a way to postpone execution of the top-level project until after all of the modules (maybe through some dark magic with a MavenSession?), I don't see how this can be done. I have gotten hold of the MavenProject instances for all of the modules through $

, so it really is just a matter of getting their $

s, merging their .ser files and modifying the ReportMojo so that it fetches the compileSourceRoots for all of POM-projects' submodules. When all of this works smoothly, I can begin worrying about inclues and excludes.

Any thoughts?

My employer has pulled me off of this task, so I won't be able to do much work on it anymore. Maybe I'll get back on it sometime, either in my spare-time or if my employer wants to see the work finished.

Either way, the files attached are what little work I've done. No changes to other files are necessary, just plop these in where they're supposed to go. I'm not sure whether what I've done with the mojo is sane, but it outputs both when run from the command line, as well as if declared in the pom.

So, if anyone wants to continue the work, have at it!

I've done some more work on this, and I'm nearly finished writing the MergeMojo. I initially wanted the aggregation to be recursive, so that in structures like this:

pom.xml

— submodule 1

— submodule 2

— pom.xml

— subsubmodule 1

— subsubmodule 2

— pom.xml

you got a cobertura.ser in submodule 2 that was the merged .ser files of subsubmodules 1 and 2, in addition to the super .ser file at the top, which is the merging of all of them.

However, due to the fact that building the project->submodule relation tree from the reactorProjects list is ridiculously tedious, I've decided to not implement this. Should this be a highly wanted feature, I'll leave it up to someone else to implement it.

Alright, we have a working implementation, complete with tests and all! :-D

This being said, even though it works in my environment and on my employer's multi-module project, I wouldn't be surprised if it's still very fragile and easily broken.

Anyways, check out the new example config - the "build" execution is only necessary when coverage checking is to be performed. To integrate the cobertura coverage report, the way to do this is:

mvn cobertura:prepare cobertura:merge site

The "prepare" mojo is just a bootstrap mojo in order to get classes instrumented and the .ser files generated. I really wanted to integrate the merge mojo better into the build lifecycle, but because of MNG-2184 @aggregator mojos can't be bound to phases - they must be run from the command line.

This, and the fact that Maven is rather indiscriminate as to how many times during a single build it will run the same tests, made this solution the one where the tests are run the LEAST amount of times.

Anyway, I hope you find it usable and decide to integrate it into the tree.

Suggestions for the future:

• The files that are to be merged are hardcoded as <submodule's basedir>/cobertura.ser - this should be changed so that it picks up on any user configuration in this respect. I understand that there is a bug in Cobertura itself that doesn't allow this, so for now I deemed it adequate to hardcode it.

• The aggregation isn't recursive. Any modules that have modules themselves should also get the option of having an aggregated report of all of their submodules. This requires the building of the infamous parent->module tree from the reactorProjects list - I have some ideas and suggestions as to how to do this, so if anyone is interested in implementing this, let me know.

PS:

The ability to control via the configuration which modules should have their .ser files merged is not implemented either. With my employer pushing to get this working, and me now being transferred (yet again) to another project, I simply did not have the time.

Just a status report for you guys here.

Any change of seeing this applied? I'd like to go with cobertura for the geotools project since we are both open source, but aggregation is something I really need... otherwise I'll have to go with clover

That one would be really great!

why you don't take a look of Dashboard-maven-plugin josted in codehaus ?

http://mojo.codehaus.org/dashboard-maven-plugin/

see "Sample reports" for single project and multi-moduls project.

It seems like the internal cobertura provided aggregation could be used instead. Is anybody using the cobertura-merge ant task to create the merged results for all projects, or does the patch accomplish the same thing? http://cobertura.sourceforge.net/anttaskreference.html. Is the merge task smart enough to understand that tests in one project module may provide additional coverage for classes in another dependent project module? Or does it simply merge all results into an existing single file?

The dashboard plugin example shows 0% coverage for the Cobertura tests (a common problem related to a customized maven configuration). It also states that "Maven's internal support for report aggregation is rather poor and does have a number of limitations. This may be addressed by an application like Sonar." at http://mojo.codehaus.org/dashboard-maven-plugin/faq.html.

Given the new aggregation support, is this still a wanted thing?

Addressed by -85.