Regression: report will not be rendered on invocation of mvn clean install site for a multi module project.

Unless you can stir up the author of MCOBERTURA-65's patch, chances are that this won't get fixed unless you are willing to fix it. It would also be helpful if you would explain in a bit more detail what 'regressed'. There didn't used to be any multi-module support other than just running in all the children. Are you claiming that this stopped working?

Yes, I am claiming this. If you check out the test project and invoke "mvn clean install site", the cobertura reports are created in the modules with tests. Now only changing the version of the plugin from 2.4 to 2.5 will always skip the creation of cobertura reports at all, the output for 2.5 looks like this:

[INFO] <<< cobertura-maven-plugin:2.5:cobertura (report:cobertura) @ app1 <<<
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 skin.
[INFO] Skipped "Cobertura Test Coverage" report, file "index.html" already exists for the English version.
[INFO] Generating "Continuous Integration" report    --- maven-project-info-reports-plugin:2.3.1

while for 2.4 it looks like this:

[INFO] Generating "Cobertura Test Coverage" report    --- cobertura-maven-plugin:2.4
[INFO] Cobertura 1.9.4.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
Cobertura: Loaded information on 1 classes.
Report time: 182ms

[INFO] Cobertura Report generation was successful.

With 2.4, when going into MODULE/target/site, there exists a directory called cobertura and
project-reports.html in the directory has a link pointing to cobertura/index.html.

With 2.5, when going into MODULE/target/site, there does not exist a directory called cobertura and
project-reports.html in the directory has a link pointing to index.html.

I will attach the complete console output for 2.4 and 2.5.

console output from invocation of mvn clean install site, only difference is the version of the cobertura plugin.

@Mirko

could you do two more things:

• check out http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/ and run mvn clean verify. It contains an integration-test specific for MCOBERTURA-65. I don't have a problem here using M3. It contains all files as you described.
• because of bullet 1 it seems to be a config-issue. Could you run mvn clean install site -X instead and post the log?

Robert,

It's possible that the patch broke the vanilla configuration that just mapped the plugin over the modules at the same time that it enabled the new syntax. The test I wrote didn't include that case. It's also possible that M3 isn't feeling as cooperative as M2 with this. Does the CI build for mojo run both M2 and M3?

--benson

Benson,

Bamboo has 2 plans: CI which runs the unit-tests and IT which runs the integration-tests.
You can only define 1 maven instance per plan, which is M2 (actually maven-2.2.1)
Like I said: it doesn't seem to be a M3 problem, ITs all run on my machine., although it would be better if the output is verified, like the generated .ser file and the reports.

@Robert:

• Did checkout from svn and ran mvn clean verify with maven 3. All tests and integration tests succeeded.
• I invoked mvn clean to get rid of propably useless info beforehand. Find attached the output of mvn -X install site.

• I stripped my project completely to only include cobertura (https://github.com/mfriedenhagen/multi-module-sample/commit/702dba7133d1bd8a679d3c4639d38883b9e74ece). Now when running mvn -Dcobertura-plugin.version=XXX clean site for both 2.4 and 2.5:
  1. cobertura-reports are created beneath MODULE/target/site/cobertura
  2. in the MODULE/target/site/project-reports.html the correct link (<a href="cobertura/index.html" title="Cobertura Test Coverage">Cobertura Test Coverage</a>) is generated.
  3. See attached file cobertura-2.5-x-without-project-reports.log

• Then I reenabled the maven-project-info-reports-plugin again. Now when running mvn -Dcobertura-plugin.version=XXX clean site:
  1. cobertura-reports (MODULE/target/site/cobertura) are only generated with 2.4
  2. in the project-reports.html the correct link (<a href="cobertura/index.html" title="Cobertura Test Coverage">Cobertura Test Coverage</a>) is only produced for 2.4, for 2.5 the
     links looks like this: (<a href="index.html" title="Cobertura Test Coverage">Cobertura Test Coverage</a>)
  3. See attached files cobertura-2.4-x-with-project-reports.log and cobertura-2.5-x-with-project-reports.log

• Using maven-project-info-reports-plugin seems to be the suggested way with Maven 3 (https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-NewConfiguration)

• I made the version of maven-project-info-reports-plugin configurable and retried with versions of maven-project-info-reports-plugin mvn -Dcobertura-plugin.version=2.5 -Dmaven-project-info-reports-plugin.version=XXX clean site.
• I tried maven-project-info-reports-plugin.version 2.0.1, 2.1.1, 2.1.2, 2.2, 2.3 and current 2.3.1, with none of which the cobertura reports were generated and links in MODULE/target/site/project-reports.html were always wrong.
• Maybe some other fix from cobertura-plugin 2.4 to 2.5 did break this, maybe this is not related to MCOBERTURA-65 at all.

I propably found the culprit by reading the diff between http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.4/src/main and http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/src/main :
In revision 18883 in src/main/java/org/codehaus/mojo/cobertura/CoberturaReportMojo.java

@@ -250,7 +354,7 @@
      */
     public String getOutputName()
     {
-        return "cobertura/index";
+        return "index";
     }

So now cobertura report generation will be skipped on mvn site, may be forced by mvn cobertura:cobertura and works in the IT because only a minimal site without project-reports is generated.

I remember making this change; the tests that we have failed before I made it. So we have a tradeoff between 'site' and 'cobertura:cobertura"?

Right now it seems so. mvn cobertura:cobertura (or mvn site without maven-project-info-reports-plugin) are just fine. However the maven-project-info-reports-plugin seems to overrule something, looks for mojo.getOutputName() and when it already exists skips execution of the rendering. I just executed mvn cobertura:cobertura with maven-project-info-reports-plugin included and it did produce cobertura reports for the two modules with Java classes.

It looks to me like the combo of the original author of -65 and didn't understand something. I'm off to seek enlightenment.

Patch MCOBERTURA-145.patch is against:

[mirko@borg cobertura-maven-plugin-2.5]$ svn info
Path: .
URL: http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5
Repository Root: http://svn.codehaus.org/mojo
Repository UUID: 52ab4f32-60fc-0310-b215-8acea882cd1b
Revision: 13979
Node Kind: directory
Schedule: normal
Last Changed Author: bimargulies
Last Changed Rev: 13936
Last Changed Date: 2011-04-18 17:05:22 +0200 (Mon, 18 Apr 2011)

What I did to test:

• Ran mvn clean verify in the plugin directory, all tests succeeded, checked target/it/mcobertura-65/target/site/cobertura and it still does hold an aggregate report for both modules.
• Ran mvn -Dcobertura-plugin.version=2.5 clean site and mvn -Dcobertura-plugin.version=2.5 clean cobertura:cobertura in my test project and in both cases the cobertura reports for the modules were created.
• Introduced <aggregate> in the parent-pom of my test project and ran mvn -Dcobertura-plugin.version=2.5 clean site again. The aggregated report as well as the reports for the modules were created.

From an expert:

Benson Margulies wrote:

MCOBERTURA-145 describes a conflict with maven-project-info-reports.
It seems as if there's some convention that the author of
MCOBERTURA-65 and I didn't understand.

http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/ProjectIndexPageReport.html#75
http://mojo.codehaus.org/cobertura-maven-plugin/xref/org/codehaus/mojo/cobertura/CoberturaReportMojo.html#401

It's been a while but AFAIR the output name of a report serves kinda as a key and should be unique, they currently clash.

You want to make a fix and I'll commit it?

Is there something wrong with the fix from comment action_264422 I provided?

No, our emails crossed. I'm getting organized to apply it.

BTW, this does not only affect multi-module projects but single module projects as well and I could reproduce this with Maven 2.2.1 as well for one sample project. So I would suggest to make this issue "critical" as I guess a lot of projects use maven-project-info-reports. And would you change the summary, please .

Mirko,

I've be really grateful for more of an explanation behind the patch. I see that you put the output back into a subdir and then made that test go up a level. Why is that better than picking a name other than plain 'index' for the output name? Why did the test fail in the first place provoking me to make the bad fix?

Benson,

as stated by the expert (glossar: maven-project-info-reports = MPIR), here my wild guesses:

• getOutputName of the childMojos is used as a sort of key during the run of MPIR.
• MIPR looks for the existence of a file called childMojo.getOutputName() + ".html" in it's own getReportOutputDirectory, resulting in target/site/index.html for cobertura without the patch and not the value target/site/cobertura/index.html as you would expect of the coberturaMojo.
• But target/site/index.html is the complete outputname of MIPR itself. As it already did start to write to this file, the file exists and so execution is skipped (sort of optimization to not run reports twice).
• Most other reporting mojos (findbugs, checkstyle) just have one output file, use target/site and name their outputName like findbugs.html or pmd.html, so no collision arises.
• You could argue, that using reportMojo.getReportOutputDirectory().getParent() in the test is just a dirty hack for getting back to target/site .
• To my understanding getOutputName() is only used by MIPR.
• The patch does not touch getReportOutputDirectory() at all, only the test is affected.

Regards
Mirko

Thank you.

Fix applied.