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
          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: