Mojo's Cobertura Maven Plugin
  1. Mojo's Cobertura Maven Plugin
  2. MCOBERTURA-145

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5.1
    • Labels:
      None
    • Environment:
      maven-3.0.3, maven-cobertura-plugin 2.5
    • Number of attachments :
      8

      Description

      When switching from 2.4 to 2.5 invocation of mvn clean install site will not render neither the html nor the xml report anymore in a multimodule project. A test project may be found at: https://github.com/mfriedenhagen/multi-module-sample/commit/62c5ec2d8bfc1c0420f7e6a701032300894eaa98.

      1. cobertura-2.4.log
        24 kB
        Mirko Friedenhagen
      2. cobertura-2.4-x.log
        700 kB
        Mirko Friedenhagen
      3. cobertura-2.4-x-with-project-reports.log
        454 kB
        Mirko Friedenhagen
      4. cobertura-2.5.log
        23 kB
        Mirko Friedenhagen
      5. cobertura-2.5-x.log
        711 kB
        Mirko Friedenhagen
      6. cobertura-2.5-x-without-project-reports.log
        288 kB
        Mirko Friedenhagen
      7. cobertura-2.5-x-with-project-reports.log
        463 kB
        Mirko Friedenhagen
      8. MCOBERTURA-145.patch
        1 kB
        Mirko Friedenhagen

        Issue Links

          Activity

          Hide
          Benson Margulies added a comment -

          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?

          Show
          Benson Margulies added a comment - 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?
          Hide
          Mirko Friedenhagen added a comment - - edited

          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.

          Show
          Mirko Friedenhagen added a comment - - edited 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.
          Hide
          Mirko Friedenhagen added a comment -

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

          Show
          Mirko Friedenhagen added a comment - console output from invocation of mvn clean install site , only difference is the version of the cobertura plugin.
          Hide
          Robert Scholte added a comment -

          @Mirko

          could you do two more things:

          Show
          Robert Scholte added a comment - @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?
          Hide
          Benson Margulies added a comment -

          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

          Show
          Benson Margulies added a comment - 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
          Hide
          Robert Scholte added a comment -

          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.

          Show
          Robert Scholte added a comment - 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.
          Hide
          Mirko Friedenhagen added a comment -

          @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.
          Show
          Mirko Friedenhagen added a comment - @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 .
          Hide
          Mirko Friedenhagen added a comment - - edited
          Show
          Mirko Friedenhagen added a comment - - edited 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: cobertura-reports are created beneath MODULE/target/site/cobertura 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. 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 : cobertura-reports ( MODULE/target/site/cobertura ) are only generated with 2.4 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> ) 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 )
          Hide
          Mirko Friedenhagen added a comment -
          • 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.
          Show
          Mirko Friedenhagen added a comment - 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.
          Hide
          Mirko Friedenhagen added a comment - - edited

          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.

          Show
          Mirko Friedenhagen added a comment - - edited 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.
          Hide
          Benson Margulies added a comment -

          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"?

          Show
          Benson Margulies added a comment - 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"?
          Hide
          Mirko Friedenhagen added a comment - - edited

          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.

          Show
          Mirko Friedenhagen added a comment - - edited 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.
          Hide
          Benson Margulies added a comment -

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

          Show
          Benson Margulies added a comment - It looks to me like the combo of the original author of -65 and didn't understand something. I'm off to seek enlightenment.
          Hide
          Mirko Friedenhagen added a comment - - edited

          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.
          Show
          Mirko Friedenhagen added a comment - - edited 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.
          Hide
          Benson Margulies added a comment -

          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?

          Show
          Benson Margulies added a comment - 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?
          Hide
          Mirko Friedenhagen added a comment -

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

          Show
          Mirko Friedenhagen added a comment - Is there something wrong with the fix from comment action_264422 I provided?
          Hide
          Benson Margulies added a comment -

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

          Show
          Benson Margulies added a comment - No, our emails crossed. I'm getting organized to apply it.
          Hide
          Mirko Friedenhagen added a comment -

          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 .

          Show
          Mirko Friedenhagen added a comment - 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 .
          Hide
          Benson Margulies added a comment -

          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?

          Show
          Benson Margulies added a comment - 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?
          Hide
          Mirko Friedenhagen added a comment -

          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

          Show
          Mirko Friedenhagen added a comment - 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
          Hide
          Benson Margulies added a comment -

          Thank you.

          Show
          Benson Margulies added a comment - Thank you.
          Hide
          Benson Margulies added a comment -

          Fix applied.

          Show
          Benson Margulies added a comment - Fix applied.

            People

            • Assignee:
              Benson Margulies
              Reporter:
              Mirko Friedenhagen
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: