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

Cobertura should aggregate results of multi-module builds

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Labels:
      None
    • Environment:
      Windows
    • Number of attachments :
      2

      Description

      When I run a cobertura report on parent pom project that has child modules I only get reports generated for each module, I also want to see a combined report in the parent.

      1. cobertura_aggregate.diff
        15 kB
        James Ahlborn
      2. MCOBERTURA-65.patch
        25 kB
        Benson Margulies

        Activity

        Hide
        Mirko Friedenhagen added a comment - - edited

        So how do I use this? I have a simple multi-module project at https://github.com/mfriedenhagen/multi-module-sample consisting of a parent-pom project, one lib (core) and two apps. However I do not get a report at all now, even for the subprojects the cobertura report is missing and no xml files are rendered as well (see http://huschteguzzel.de/hudson/job/test-multimodule/). I use maven-3.0.3 and invoke mvn clean install site. Configuration for cobertura in the parent-pom is at line 200

        Show
        Mirko Friedenhagen added a comment - - edited So how do I use this? I have a simple multi-module project at https://github.com/mfriedenhagen/multi-module-sample consisting of a parent-pom project, one lib (core) and two apps. However I do not get a report at all now, even for the subprojects the cobertura report is missing and no xml files are rendered as well (see http://huschteguzzel.de/hudson/job/test-multimodule/ ). I use maven-3.0.3 and invoke mvn clean install site . Configuration for cobertura in the parent-pom is at line 200
        Hide
        Benson Margulies added a comment -

        https://svn.codehaus.org/mojo/trunk/mojo/cobertura-maven-plugin/src/it/mcobertura-65

        See this integration test for an example, and in general use the user list for assistance.

        Show
        Benson Margulies added a comment - https://svn.codehaus.org/mojo/trunk/mojo/cobertura-maven-plugin/src/it/mcobertura-65 See this integration test for an example, and in general use the user list for assistance.
        Hide
        Miten Morakhia added a comment -

        1.
        I upgraded to sonar 2.5.1 for my project by putting in the following configuration but do not see the results getting merged.

        <reporting>
        <plugins>
        <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
        <version>2.5.1</version>
        <configuration>
        <aggregate>true</aggregate>
        </configuration>
        </plugin>

        Is this configuration setting correct?

        2.
        We use teamcity for continuous integration and have sonar for doing code analysis.
        I see the following warning in the log files during sonar build.

        [cobertura] WARN [main] net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number information found for class com.test.BumpKey$1. Perhaps you need to compile with debug=true?

        In the build configuration, I have already added "-Ddebug=true" in the "Additional Maven command line parameters" section.
        Is there any other change required for getting the anonymous inner classes included in code coverage analysis?

        Show
        Miten Morakhia added a comment - 1. I upgraded to sonar 2.5.1 for my project by putting in the following configuration but do not see the results getting merged. <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.5.1</version> <configuration> <aggregate>true</aggregate> </configuration> </plugin> Is this configuration setting correct? 2. We use teamcity for continuous integration and have sonar for doing code analysis. I see the following warning in the log files during sonar build. [cobertura] WARN [main] net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number information found for class com.test.BumpKey$1. Perhaps you need to compile with debug=true? In the build configuration, I have already added "-Ddebug=true" in the "Additional Maven command line parameters" section. Is there any other change required for getting the anonymous inner classes included in code coverage analysis?
        Hide
        Neil Ingle added a comment -

        I have not got either patch (2.5-SNAPSHOT or 2.5.1) to work in the way that I understood they would - that of collecting and consolidating coverage statistics across modules, so that if you have a test in module A which exercises classes in modules B and C, then the consolidated report would show classes in all three modules A, B, and C.

        Currently the reports either only display classes in the same module, or display classes from other modules with 0% coverage. I accept that you can't expect to cover library classes - but these are Maven modules (as well as libraries), which are treated as 'siblings' under the umbrella of a multi-module POM project.

        Maybe what is required is to produce a consolidated instrumented SER file (which does seem to happen - "consolidate-cobertura.ser" is created in the target directory of the parent project) and then drive all coverage from that, rather than individual sub-module SER files. It looks as if both patches are just running tests and generating coverage inside modules, and then consolidating.

        Show
        Neil Ingle added a comment - I have not got either patch (2.5-SNAPSHOT or 2.5.1) to work in the way that I understood they would - that of collecting and consolidating coverage statistics across modules, so that if you have a test in module A which exercises classes in modules B and C, then the consolidated report would show classes in all three modules A, B, and C. Currently the reports either only display classes in the same module, or display classes from other modules with 0% coverage. I accept that you can't expect to cover library classes - but these are Maven modules (as well as libraries), which are treated as 'siblings' under the umbrella of a multi-module POM project. Maybe what is required is to produce a consolidated instrumented SER file (which does seem to happen - "consolidate-cobertura.ser" is created in the target directory of the parent project) and then drive all coverage from that, rather than individual sub-module SER files. It looks as if both patches are just running tests and generating coverage inside modules, and then consolidating.
        Hide
        James Ahlborn added a comment -

        @Neil - you are correct. your desired behavior is actually a harder problem. it's not a matter of just having a consolidated ser file, it's a matter of running your tests for module A using instrumented classes for A,B, and C. currently, the instrumented classes only live inside the target directory of the sub-module. however, maven, i believe, actually pulls the other sub-module classes from your local repository (e.g. when you are running tests for A, the classes for B and C are coming from your repository). so you essentially need to temporarily deploy the instrumented classes for B and C to your local repository (and presumably overwrite them when you are done). there may be a way to use some serious maven magic to add the instrumented sub-module classes from B's and C's target directory to A's classpath on the fly during test execution, but that's way beyond my maven plugin knowledge.

        Show
        James Ahlborn added a comment - @Neil - you are correct. your desired behavior is actually a harder problem. it's not a matter of just having a consolidated ser file, it's a matter of running your tests for module A using instrumented classes for A,B, and C. currently, the instrumented classes only live inside the target directory of the sub-module. however, maven, i believe, actually pulls the other sub-module classes from your local repository (e.g. when you are running tests for A, the classes for B and C are coming from your repository). so you essentially need to temporarily deploy the instrumented classes for B and C to your local repository (and presumably overwrite them when you are done). there may be a way to use some serious maven magic to add the instrumented sub-module classes from B's and C's target directory to A's classpath on the fly during test execution, but that's way beyond my maven plugin knowledge.

          People

          • Assignee:
            Benson Margulies
            Reporter:
            David Hoffer
          • Votes:
            70 Vote for this issue
            Watchers:
            56 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: