Cobertura Plugin

Plugin Information

Plugin ID cobertura
Latest Release 1.6-h-3
Latest Release Date Jan 14, 2013
Sources Github
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla

This plugin allows you to capture code coverage report from Cobertura. Hudson will generate the trend report of coverage.
The Cobertura plug in can be downloaded here.

Configuring the Cobertura Plugin

  1. Install the cobertura plugin (via Manage Hudson -> Manage Plugins)
  2. Configure your project's build script to generate cobertura XML reports (See below for examples with Ant and Maven2)
  3. Enable the "Publish Cobertura Coverage Report" publisher
  4. Specify the directory where the coverage.xml report is generated.
  5. (Optional) Configure the coverage metric targets to reflect your goals.

Configuring build tools

Here are the configuration details for common build tools. Please feel free to update this with corrections or additions. 

Maven 2

Quick configuration

You can either, enable "cobertura" analysis in your 'pom.xml' files or just tell Hudson to run "cobertura" goal.

If you don't want to change your pom files, just add the goal 'cobertura:cobertura' to your Maven project in Hudson.

Single Project

If you are using a single module configuration, add the following into your pom.xml. This will cause cobertura to be called each time you run "mvn package".

<project ...>
    ...
    <build>
        ...
        <plugins>
            ...
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>cobertura-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <formats>
                        <format>xml</format>
                    </formats>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>cobertura</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            ...
        </plugins>
        ...
    </build>
    ...
</project>




Execute cobertura only from hudson using profiles

You can reduce the load of your developer machine by using maven profiles to execute the plugin only if you are running within hudson. Theconfiguration below shows how to enable the plugin based on the information if maven was started by hudson.


<project ...>
    ...
    <profiles>
        <!-- Hudson by default defines a property BUILD_NUMBER which is used to enable the profile. -->
        <profile>
            <id>hudson</id>
            <activation>
                <property>
                    <name>BUILD_NUMBER</name>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>cobertura-maven-plugin</artifactId>
                        <version>2.2</version>
                        <configuration>
                            <formats>
                                <format>xml</format>
                            </formats>
                        </configuration>
                        <executions>
                            <execution>
                                <phase>package</phase>
                                <goals>
                                    <goal>cobertura</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
    ...
</project>

Project hierarchies

If you are using a common parent for all Maven2 modules you can move the plugin configuration to the pluginManagement section of the common parent...

<project ...>
    ...
    <build>
        ...
        <pluginManagement>
            <plugins>
                ...
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>cobertura-maven-plugin</artifactId>
                    <version>2.2</version>
                    <configuration>
                        <formats>
                            <format>xml</format>
                        </formats>
                    </configuration>
                    <executions>
                        <execution>
                            <phase>package</phase>
                            <goals>
                                <goal>cobertura</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                ...
            </plugins>
        </pluginManagement>
        ...
    </build>
    ...
</project>

 And add the plugin group and artifact to the children

<project ...>
    ...
    <build>
        ...
        <plugins>
            ...
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>cobertura-maven-plugin</artifactId>
            </plugin>
            ...
        </plugins>
        ...
    </build>
    ...
</project>

Execute cobertura only from hudson using profiles

It is highly recommend to reduce the workload of the developers machines by disabling the cobertura plugin and only using it from within hudson. The following excerpt from the parent shows how to do so:

<project ...>
    ...
    <profiles>
        <!-- Hudson by default defines a property BUILD_NUMBER which is used to enable the profile. -->
        <profile>
            <id>hudson</id>
            <activation>
                <property>
                    <name>BUILD_NUMBER</name>
                </property>
            </activation>
            <build>
                <pluginManagement>
                    <plugins>
                        <plugin>
                            <groupId>org.codehaus.mojo</groupId>
                            <artifactId>cobertura-maven-plugin</artifactId>
                            <version>2.2</version>
                            <configuration>
                                <formats>
                                    <format>xml</format>
                                </formats>
                            </configuration>
                            <executions>
                                <execution>
                                    <phase>package</phase>
                                    <goals>
                                        <goal>cobertura</goal>
                                    </goals>
                                </execution>
                            </executions>
                        </plugin>
                    </plugins>
                </pluginManagement>
            </build>
        </profile>
    </profiles>
    ...
</project>

 Now that your parent is only using the plugin management section if it is running from within hudson, you need the childern poms adapted as well:

<project ...>
    ...
    <!-- If we are running in hudson use cobertura. -->
    <profiles>
        <profile>
            <id>hudson</id>
            <activation>
                <property>
                    <name>BUILD_NUMBER</name>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>cobertura-maven-plugin</artifactId>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
    ...
</project>

Ant

You must first tell Ant about the Cobertura Ant tasks using a taskdef statement. The best place to do this is near the top of your build.xml script, before any target statements.

<property name="cobertura.dir" value="C:/javastuff/cobertura" />

<path id="cobertura.classpath">
    <fileset dir="${cobertura.dir}">
        <include name="cobertura.jar" />
        <include name="lib/**/*.jar" />
    </fileset>
</path>

<taskdef classpathref="cobertura.classpath" resource="tasks.properties" />

You'll need to instrument the classes that JUnit will be testing (not the test classes themselves) as such:

<cobertura-instrument todir="${instrumented.dir}">
    <ignore regex="org.apache.log4j.*" />
    <fileset dir="${classes.dir}">
        <include name="**/*.class" />
        <exclude name="**/*Test.class" />
    </fileset>
    <fileset dir="${guiclasses.dir}">
        <include name="**/*.class" />
        <exclude name="**/*Test.class" />
    </fileset>
    <fileset dir="${jars.dir}">
        <include name="my-simple-plugin.jar" />
    </fileset>
</cobertura-instrument>

Here's an example call to the JUnit ant task that has been modified to work with Cobertura. 

<junit fork="yes" dir="${basedir}" failureProperty="test.failed">
	<!--
		Specify the name of the coverage data file to use.
		The value specified below is the default.
	-->
	<sysproperty key="net.sourceforge.cobertura.datafile"
		file="${basedir}/cobertura.ser" />

	<!--
		Note the classpath order: instrumented classes are before the
		original (uninstrumented) classes.  This is important.
	-->
	<classpath location="${instrumented.dir}" />
	<classpath location="${classes.dir}" />

	<!--
		The instrumented classes reference classes used by the
		Cobertura runtime, so Cobertura and its dependencies
		must be on your classpath.
	-->
	<classpath refid="cobertura.classpath" />

	<formatter type="xml" />
	<test name="${testcase}" todir="${reports.xml.dir}" if="testcase" />
	<batchtest todir="${reports.xml.dir}" unless="testcase">
		<fileset dir="${src.dir}">
			<include name="**/*Test.java" />
		</fileset>
	</batchtest>
</junit>

Finally, you need a task to generate the xml report, where 'destdir' is where you want the report (coverage.xml) generated.

Your cobertura.ser is generated to your module root.

srcdir is where your *.java files are located. If you use multiple modules in one build process you need to include the module name, if you use the simple srcdir parameter. It is not required to include module name if you use fileset.

<cobertura-report format="xml" destdir="${coveragereport.dir}" srcdir="${src.dir}" />
You can use multiple source directories this way:
<cobertura-report format="xml" destdir="${coveragereport.dir}" >

	<fileset dir="${src.dir.java}">

		<include name="**/*.java" />

	</fileset>

	<fileset dir="${src.dir.main}">

		<include name="**/*.java" />

	</fileset>

</cobertura-report>



Version History

Compatibility Info
The plug-in is being maintained by its owner/maintainers from a [new home:[https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin]]. Check the Tier info for details of compatibility

Version 1.1 (11-Jan-2011)

Version 1.0 (30-Jul-2010)

  • Fix so 0/0 is counted as 100% instead of 0% coverage (ie, a method with no conditionals). (issue #6790)
  • Fix in source viewer so "\n" and "\r" (backslash+n/r, not actual newlines) are not omitted. (issue #3566)
  • Add support for dashboard plugin

Version 0.8.11 (22-Mar-2010)

  • Fixed: source code unavailable when unstable (issue #4803)
  • Fixed an issue in internationalization on static enum clases which made some texts be shown in English.
  • Fixed a bug in the way the tables were sorted (same problem than emma issue #4173). Now they are sorted numerically instead of alphabetically.
  • Added Spanish internationalization.

Version 0.8.10 (15-Jan-2010)

  • Reorganize data structures to allow processing larger result files
  • Use EnumMap and EnumSet for more compact in-memory representation of data
  • Update code for more recent Hudson
  • Change report colors as described here
  • Internationalize messages (issue #4920)

Version 0.8.9 (8-Jul-2009)

  • Added green/red results bars to statistic blocks (issue #3869)
  • Improved support for multi-module SCMs other than Subversion (such as CVS) (issue #1323)
  • Fixed an issue that broke source highlighting for module build result pages (issue #3938)

Version 0.8.8 (11-Jun-2009)

  • Revert the memory usage fixes in 0.8.7, since they were breaking source highlighting (issue #3597)

Version 0.8.7 (4-Jun-2009)

  • Improved help and error messages to attempt to avoid "Can not find coverage-results" (issue #1423)
  • Fixed "Consider only stable builds" setting (issue #3475)
  • Improved memory usage when drawing trend graphs (issue #3597)

Version 0.8.6 (7-May-2009)

  • The plugin runs before notifications are sent out, to avoid inconsistency in build status reporting (issue #1285)
  • The cobertura statistics graphic on a project window isn't rendered (issue #2851)

Version 0.8.4 (21-Oct-2007)

  • ???

Version 0.8.3 (12-Oct-2007)

Version 0.8.2 (4-Oct-2007)

Version 0.8.1 (28-Sep-2007)

  • Fixes issues running under JDK 1.5
  • Fixes some issues with finding source code

Version 0.8 (20-Sep-2007)

  • Works with JDK 5 as well as JDK 6 (removing JDK dependency introduced during regression fixing)

Version 0.7 (20-Sep-2007)

  • Better fix of regressions introduced in 0.5

Version 0.6 (20-Sep-2007)

  • Fix of regressions introduced in 0.5

Version 0.5 (20-Sep-2007)

  • Now with built in source code painting! (Source code is available at the file level for the latest stable build only).

Note that the conditional coverage is the highest coverage from all the cobertura reports aggregated in  each build.  Thus if you have two reports and one covers only 50% of a conditional and the other covers a different 25%, conditional coverage will be reported as 50% and not the 75% that you could argue it should be!

  • The trend graph now works when there are broken builds in the build history.

Version 0.4 (29-Aug-2007)

  • Initial support for multi-report aggregation (may get totals incorrect if reports overlap for individual classes - I'll need to get source file painting support implemented to remove that issue.  However, this is just how the files are parsed.  This version will archive the files correctly so when it is fixed your history should report correctly)

Version 0.3 (28-Aug-2007)

  • Fixed NPE parsing some cobertura reports generated by Cobertura version 1.8.
  • Project level report should now work (except possibly when a build is in progress) 

Version 0.2 (28-Aug-2007)

  • Fixed problem with configuration (was not persisting configuration details)
  • Changed health reporting configuration (now handles the more generic code)
  • Tidy-up of reports
  • Known issues:
    • Project level report does not work in all cases
    • Class and Method level reports should display source code with coverage if source code is available (in workspace) 

Version 0.1 (27-Aug-2007)

  • Initial release.  Only parses xml report. Some rough edges in the UI.

Labels:

plugin-maven plugin-maven Delete
plugin-report plugin-report Delete
tier3-installtest-plugin tier3-installtest-plugin Delete
tier2-plugin tier2-plugin Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Sep 02, 2007

    Anonymous says:

    After some hours, I got it to work with the Netbeans makefile. The handling of...

    After some hours, I got it to work with the Netbeans makefile.

    The handling of build.properties and project.properties was a bit tricky for me as a novice Ant user, because I don't wanted to "pollute" the other workstations in our working group with dependencies to cobertura. Besides, there seems to be a bug with the datafile attribute, which should define the position of cobertura.ser, but in fact this attribute doesn't work correctly.

    I was a bit dissapointed about the graphical representation of the Cobertura report in the Hudson plugin, knowing the HTML report of Cobertura. Isn't there a possibility to let Cobertura produce the HTML report and put a link to it in Hudson?

    But alltogether I became an entusiastic user of Hudson in the last four days! It's really an excellent tool.

    1. Sep 20, 2007

      Stephen Connolly says:

      Could you please add a section into this page detailing how to get this plugin w...

      Could you please add a section into this page detailing how to get this plugin working with the Netbeans makefile?

      1. Sep 23, 2007

        Jessica-Aileen says:

        There is no magic with it. I've simply used the advices from this blog: http://w...

        There is no magic with it. I've simply used the advices from this blog: http://weblogs.java.net/blog/fabriziogiudici/archive/2006/11/setting_up_netb.html

        If I have more time I'll post my configuration for findbugs, violations (pmd, findbugs, cpd, checkstyle) and cobertura. But it shouldn't be a problem with Fabrizios blog entry to make a suitable buildfile.

  2. Sep 02, 2007

    Anonymous says:

    I agree with the previous poster -- the HTML reports generated by Cobert...

    I agree with the previous poster -- the HTML reports generated by Cobertura are great.  My ANT file already generates those -- so what I want (in addition to the timeline graph) is to put a link to the coverage reports in my build status page.  That has to be easy, right?

  3. Sep 14, 2007

    Anonymous says:

    +1 for integrating the plain Cobertura reports in some way or another. The ...

    +1 for integrating the plain Cobertura reports in some way or another.

    The plugin is great by the way ;) 

  4. Sep 19, 2007

    Stephen Connolly says:

    The issue with integrating the plain Cobertura reports is that this plugin is ag...

    The issue with integrating the plain Cobertura reports is that this plugin is aggregating multiple cobertura reports, so I have to generate the HTML report by hand.  The code for this is getting close to ready, but I was on holidays and have a backlog in work before I can get to it.

    1. Sep 20, 2007

      Stephen Connolly says:

      See Version 0.5 which was released today

      See Version 0.5 which was released today

      1. Sep 21, 2007

        Anonymous says:

        The HTML coverage report is produced now - but there is a problem: The plug...

        The HTML coverage report is produced now - but there is a problem: The plugin doesn't include it! It seems to be that the plugin ist awaiting the HTML report in a "hard wired" directory named "cobertura" in the jobname-directory under jobs.

        There should be a possibility to tell the plugin where the destination directory is - in the same way that you define the "Cobertura xml report pattern" in the project configuration.

        At the moment I can't find out how to tell cobertura to use the hard-wired directory - but it is nearly midnight now.

        1. Sep 21, 2007

          Anonymous says:

          It makes no difference if the report is in the cobertura directory or elsewhere:...

          It makes no difference if the report is in the cobertura directory or elsewhere: The plugin claims "Source code is unavailable". Two minutes past midnight now ...

          1. Sep 22, 2007

            Stephen Connolly says:

            The source code will only be available for the most recent build.  Disk spa...

            The source code will only be available for the most recent build.  Disk space is cheap, but not cheap enough to save it for every build.  Also, there is not much use in knowing the past source code coverage (and there is the method level coverage for such anyway)

            If you are not seeing the source code for the most recent build, please file an issue and I'll have a look.

            1. Sep 22, 2007

              Anonymous says:

              Perhaps I misunderstood what you meant - the report is produced and I can access...

              Perhaps I misunderstood what you meant - the report is produced and I can access it via the workspace hierarchy in hudson. But there is no link in the report itself. Where I assume it should be, in the detailed report generated by the plugin, there is only the text "Source code is unavailable".

              Where can I file the issue - in the hudson issue tracker?

              1. Sep 23, 2007

                Stephen Connolly says:

                Yes the issue tracker is the best place for it. The basic idea is that the plug...

                Yes the issue tracker is the best place for it.

                The basic idea is that the plugin goes looking for the source code in all the places that cobertura says it could have been.  If it did not find the source code then you won't see it.

                what version of cobertura are you using (most of my testing is with 1.9)

                1. Sep 23, 2007

                  Jessica-Aileen says:

                  I've filed it as https://hudson.dev.java.net/issues/show_bug.cgi?id=846
  5. Oct 11, 2007

    Anonymous says:

    The plugin does not work. I have Cobertura successfully generating both HTML and...

    The plugin does not work. I have Cobertura successfully generating both HTML and XML reports as part of the build. I have the XML pattern set in the plugin configuration and it's able to find it successfully. But that's where the magic stops.

     Here is the output from the log:Recording test results
    Publishing Cobertura coverage report...
    Publishing Cobertura coverage results...
    FATAL: /local/bamboo/.hudson/jobs/MYJOB/cobertura/com/foo/dec/framework/dataAccessServices (Is a directory)
    java.io.FileNotFoundException: /local/bamboo/.hudson/jobs/MYJOB/cobertura/com/foo/dec/framework/dataAccessServices (Is a directory)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
    at hudson.FilePath.write(FilePath.java:600)
    at hudson.plugins.cobertura.renderers.SourceCodePainter.paintSourceCode(SourceCodePainter.java:48)
    at hudson.plugins.cobertura.renderers.SourceCodePainter.invoke(SourceCodePainter.java:127)
    at hudson.plugins.cobertura.renderers.SourceCodePainter.invoke(SourceCodePainter.java:28)
    at hudson.FilePath.act(FilePath.java:280)
    at hudson.plugins.cobertura.CoberturaPublisher.perform(CoberturaPublisher.java:250)
    at hudson.model.Build$RunnerImpl.post2(Build.java:138)
    at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:244)
    at hudson.model.Run.run(Run.java:597)
    at hudson.model.Build.run(Build.java:103)
    at hudson.model.ResourceController.execute(ResourceController.java:66)
    at hudson.model.Executor.run(Executor.java:62)

    1. Oct 21, 2007

      Anonymous says:

      Have you filed an issue with respect to this? The best way to get attention is ...

      Have you filed an issue with respect to this?

      The best way to get attention is to file an issue or post on the mailing list.

  6. Oct 24, 2007

    Anonymous says:

    Recenty, I am getting the following error when displayng the graph@: Status Cod...

    Recenty, I am getting the following error when displayng the graph@:

    Status Code: 500

    Exception:
    Stacktrace: java.lang.LinkageError: hudson/util/ChartUtil
    at hudson.plugins.cobertura.targets.CoverageResult.doGraph(CoverageResult.java:298)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:103)
    at org.kohsuke.stapler.Function.bindAndinvoke(Function.java:59)
    at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:63)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:294)
    at org.kohsuke.stapler.MetaClass$15.dispatch(MetaClass.java:361)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:294)
    at org.kohsuke.stapler.MetaClass$7.doDispatch(MetaClass.java:208)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:294)
    at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:240)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:294)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:231)
    at org.kohsuke.stapler.Stapler.service(Stapler.java:79)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
    at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
    at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
    at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
    at hudson.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:79)
    at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
    at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
    at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
    at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
    at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
    at java.lang.Thread.run(Unknown Source)
    Any  ideas what maybe wrong?

    1. Oct 24, 2007

      Anonymous says:

      PRETTY PLEASE WITH CATNIP ON TOP! File an issue Or at least post your ques...

      PRETTY PLEASE WITH CATNIP ON TOP!

      File an issue

      Or at least post your question on the mailing list

      Nobody is watching this comments section

  7. Oct 31, 2007

    Anonymous says:

    The instructions above say that examples for maven and ant are below. I don't se...

    The instructions above say that examples for maven and ant are below. I don't see any such examples. Maybe they could be more attention-getting. thanks.

    1. Nov 02, 2007

      Anonymous says:

      i second that.

      i second that.

      1. Nov 16, 2007

        Stephen Connolly says:

        MORE PRETTY PLEASE WITH EXTRA CATNIP ON TOP! This is a Wiki.  If you s...

        MORE PRETTY PLEASE WITH EXTRA CATNIP ON TOP!

        This is a Wiki.  If you spot something that is incorrect, please correct it.  If you spot something that is missing, please add it.  If you spot something that should be there but is not, please add a placeholder. 

        1. Mar 27, 2008

          Mike Haller says:

          Stephen, i tried to query the issue tracker but no luck. The dev.java.net issue ...

          Stephen, i tried to query the issue tracker but no luck. The dev.java.net issue tracker is very unusable. Userfriendlyness equals zero.

          According to the current version of SourceCodePainter in source control, there have already been changes. Do you know the cause of the FileNotFound Exception or how to circumvent this issue?

  8. Dec 12, 2007

    Mike Caron says:

    Just started using this. Really cool work, but it seems like the HTML reports ge...

    Just started using this. Really cool work, but it seems like the HTML reports gen'd by the plugin always report 100%, even though the weather is accurate and the file view reports correct red and green lines. I became an observer so that I could grab the code and work on it. I also like the idea of linking the "Coverage Report" to the original HTML reports, so I was going to do that too. Of course, I'd provide patches. But I first need code access...

  9. Jun 02, 2008

    fabrice says:

    I use Hudson ver. 1.219 and I verified my cobertura config matches this on ...

    I use Hudson ver. 1.219 and I verified my cobertura config matches this on this webpage, HTML and XML files are generated in target/site/cobertura but there is no image generated on the job page, no link which allow me to see cobertura reports and trends.

     I think it is a bug.

  10. Jun 03, 2008

    Jose Muanis says:

    Just updated hudson to 1.220, cobertura plugin version 0.8.4 Build ok, coverage...

    Just updated hudson to 1.220, cobertura plugin version 0.8.4

    Build ok, coverage.xml being generated just as expected in this tutorial. but I get no image nor link on the status page.

    No kind of errors in the log file.

     Any ideas where I can find information to help finding this bug?

    1. Jun 04, 2008

      fabrice says:

      ouf I am not alone on this new problem help us

      ouf I am not alone on this new problem

      help us

      1. Jun 04, 2008

        Jose Muanis says:

        Fabrice,  I've checked out version 0.8.5-SNAPSHOT and its working.  ...

        Fabrice,

         I've checked out version 0.8.5-SNAPSHOT and its working.

         But anyway, the coverage reports only apper at module page

        1. Jun 05, 2008

          fabrice says:

          Ok nice It would be nice too if we have a new stable release. When ?

          Ok nice

          It would be nice too if we have a new stable release. When ?

    2. Apr 01, 2009

      Natalie Vaslavsky says:

      Jose, I have the same problem " Build ok, coverage.xml being generated just as...

      Jose,

      I have the same problem "

      Build ok, coverage.xml being generated just as expected in this tutorial. but I get no image nor link on the status page."

      I use cobertura plugin version 0.8.4.

      Have you bee able to solve?

  11. Jun 18, 2008

    truong van nga says:

    Hi, have you some news about a stable release of this plugin? I can only downlo...

    Hi, have you some news about a stable release of this plugin?

    I can only download the  0.8.4 which is not working
    the report don't appear on the web site (but my coverage.xml are generated)

    Is the   0.8.5-SNAPSHOT always available? and where?

  12. Jun 26, 2008

    Nicolas Ruffel says:

    Hi, I have the same issue plus another one. I have a main project with lots of ...

    Hi, I have the same issue plus another one.

    I have a main project with lots of sub-projects. I configured only one job for the main project (using maven2) and it calls allthe sub modules. Great. But I want the cobertura reports generated without running the tests twice.

    If I call the goal "install", cobertura is not run. If I run "cobertura:cobertura", some modules  are tested with some old dependencies since some new packages haven't been "installed" in the repository. "install cobertura:cobertura" works, but it runs tests twice.

    What am I doing wrong?

    Thanks for your hints

    1. Sep 17, 2008

      Ramil Israfilov says:

      Hi, in order to execute cobertura during test phase just add following in your r...

      Hi,
      in order to execute cobertura during test phase just add following in your root pom.xml file

                    <groupId>org.codehaus.mojo</groupId>
                      <artifactId>cobertura-maven-plugin</artifactId>
                      <version>2.2</version>
                      <executions>
                          <execution>
                              <phase>test</phase>
                              <goals>
                                  <goal>cobertura</goal>
                              </goals>
                          </execution>
                      </executions>
                    </groupId>
      

      After that cobertura task will be executed during test phase.
      But how to avoid execution of tests twice I don't know.

  13. Dec 02, 2008

    John Allen says:

    Is there any plans to make this work with the built-in maven 2 project type? doh...

    Is there any plans to make this work with the built-in maven 2 project type? doh, its already there! its just that i'm running a custom cobertura mojo called report-only and that was being detected by the hudson cobertura plugin. reports don't seem aggregated though...

  14. Jan 08, 2009

    Dmitry Kudryavtsev says:

    Hello. I've discovered that plugin doesn't work correctly if your build is unst...

    Hello.

    I've discovered that plugin doesn't work correctly if your build is unstable. For example if some of your unit tests failed then you got "Source code is unavailable" message although all reports are gathered and you can see coverage rate. Global link to cobertura report also would be broken or invalid because you may not have any live stable build  or you last stable build is not actual

    So I looked into code and noticed that method isSourceFileAvailable in CoverageResult.class looks like "... owner == owner.getProject().getLastStableBuild() && blah-blah-blah ...".

    I think this is not really good, because in TDD you always have some errors in tests, so you would never see source code.

    Maybe it is better to change code of isSourceFileAvailable to something like "...getProject().getLastSuccessfulBuild()..." and also fix urls that is generated by CoberturaProjectAction.class ?

    I would like to contribute patch but I'm not sure how to do it.

    And sorry for my bad English  - it is not my native language.

  15. Mar 11, 2009

    witek says:

    There is a way to avoid doubled testing. We have added new "generate-report" goa...

    There is a way to avoid doubled testing. We have added new "generate-report" goal to cobertura-maven-plugin, so you can instrument code before tests and generate xml report when tests (or integration-tests) phase is finished. See top.touk.pl

    1. Apr 16, 2009

      Brian Lalor says:

      Have you released this modified plugin? I'm not able to find any more informatio...

      Have you released this modified plugin? I'm not able to find any more information on top.touk.pl than what's in your blog post there.

    2. Mar 04, 2010

      Douglas Ferguson says:

      Doesn't seem to be available anymore?

      Doesn't seem to be available anymore?

  16. Apr 02, 2009

    Daniel Rudman says:

    Hi, I am using Maven2/SVN and the latest Hudson Cobertura plugin 0.8.5. I have t...

    Hi,
    I am using Maven2/SVN and the latest Hudson Cobertura plugin 0.8.5. I have the coverage report generated and all the settings set correctly, but I do not see the coverage report in Hudson either in the job or module pages. No errors in the log either. Any ideas of how else I can debug? Pretty much stuck.

    Thanks!

    1. Apr 09, 2009

      Natalie Vaslavsky says:

      What version of Hudson can be used with cobertura plugin 0.8.5. I have 1.226. ...

      What version of Hudson can be used with cobertura plugin 0.8.5.

      I have 1.226.

      I have a hudson error while configuring a project.

      Thanks

  17. May 14, 2009

    Joaquin Morcate says:

    Hi, I'm using  Hudson 1.304 and Cobertura plugin 0.8.6. In my build.xml fi...

    Hi,

    I'm using  Hudson 1.304 and Cobertura plugin 0.8.6. In my build.xml file I have the following that works fine when I build from the command line but it keeps on complaining about the task definition when is build by hudson. Any idea? Thank you.

        <property name="cobertura.dir" location="/usr/share/tools/cobertura-1.9.1" />
        <path id="cobertura.classpath">
            <fileset dir="${cobertura.dir}">
                <include name="cobertura.jar" />
                <include name="lib/**/*.jar" />
            </fileset>
        </path>
        <taskdef classpathref="cobertura.classpath" resource="tasks.properties" />
     
    
  18. Jul 09, 2009

    Adam Armistead says:

    Hello, I'm using Hudson 1.34 and Cobertura plugin 0.8.9 with Maven 2.  Whe...

    Hello,

    I'm using Hudson 1.34 and Cobertura plugin 0.8.9 with Maven 2.  When hudson builds the coverage.xml files they are corrupted.  If I build my project in my IDE they are fine.  Here is an example of they look like when hudson builds them.

     PK
         uØ:                   META-INF/PK
       uØ:èl Cw   †      META-INF/MANIFEST.MFM‹½
    Â0€÷@ÞáFT- Ö©Ðê ¸Ê5ž˜Á«Ü¥HßÞ¸¹~?r~w%Ñ<ñ¢Ö4üGš7¦'AeUî}´æ(„...î®]~ý·[ܺ1l`u™†œdÒE½:N~mÍ
         uØ:               org/PK
         uØ:            
       org/netbeans/PK
    

    It produces a coverage.xml file and several coverage#.xml files where the # is a number 1-10.  Some of the numbered files appear to be more or less mangled copies of some of my .java files.  It puts them in the .hudson/jobs/<MyProject>/builds/<Current build date and time> directory and then fails the build saying it can't parse them, which is no surprise.  I have tried putting my cobertura plugin config stuff in my build tags or in my reporting tags or in both places in my pom, I have even just cut and pasted the config at the top of this page for the Single Project type and it all comes out the same.  It does however work correctly with the maven "site" goal both with html and xml.  Anyone know what I'm doing wrong that makes it not work with hudson?

    1. Jul 15, 2009

      Christoph Brill says:

      I have the same issues. The cobertura plugin seems to copy everything from the s...

      I have the same issues. The cobertura plugin seems to copy everything from the source directory ... even the stuff from my ".git"-SCM directory (I found a hook as coverage8.xml). I think 0.8.9 is bugged.

      Edit:

      Maybe hudson is bugged? I downgraded to 0.8.7 and the problem still persists. I'm running Hudson 1.315.

  19. Oct 12, 2009

    John Bolton says:

    We have two build machines running Hudson, one Linux (openSUSE) and the other Wi...

    We have two build machines running Hudson, one Linux (openSUSE) and the other Windows 2003. The plug-in works great on Linux, but it does not work on Windows. In fact, it causes the builds to fail. Both build machines are configured with the same version of the various components used.

    We're using version 1.326 of Hudson, Maven version 2.2.1, JDK 1.6 update 16, and version 0.8.9 of this plug-in.

    We have a parent POM that references child POM's via the <modules/> tag.

    Does anybody have any ideas why this is crashing?

    [INFO] Cobertura Report generation was successful.
    [HUDSON] Recording coverage results
    [INFO] ------------------------------------------------------------------------
    [ERROR] FATAL ERROR
    [INFO] ------------------------------------------------------------------------
    [INFO] org.apache.maven.plugin.PluginManagerException.<init>(Ljava/lang/String;Ljava/lang/Exception;)V
    [INFO] ------------------------------------------------------------------------
    [INFO] Trace
    java.lang.NoSuchMethodError: org.apache.maven.plugin.PluginManagerException.<init>(Ljava/lang/String;Ljava/lang/Exception;)V
    	at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:195)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    	at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
    	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    	at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:597)
    	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    	at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    	at hudson.maven.agent.Main.launch(Main.java:165)
    	at hudson.maven.MavenBuilder.call(MavenBuilder.java:159)
    	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:687)
    	at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:633)
    	at hudson.remoting.UserRequest.perform(UserRequest.java:104)
    	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    	at hudson.remoting.Request$2.run(Request.java:244)
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    	at java.lang.Thread.run(Thread.java:619)
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 5 minutes 41 seconds
    [INFO] Finished at: Tue Sep 29 16:01:53 PDT 2009
    [INFO] Final Memory: 23M/104M
    [INFO] ------------------------------------------------------------------------
    channel stopped
    Skipping Cobertura coverage report as build was not UNSTABLE or better ...
    

    Thanks for your time,

    John

    1. Jan 13, 2010

      John Bolton says:

      FYI, I reinstalled the OS and all of the software. The problem has gone away. I'...

      FYI, I reinstalled the OS and all of the software. The problem has gone away. I'm not sure what caused the problem however I don't believe the plug-in was doing anything wrong.

  20. Dec 03, 2009

    Chris Moesel says:

    I've noticed that this plug-in shows method coverage stats -- but cobert...

    I've noticed that this plug-in shows method coverage stats -- but cobertura html reports don't show method coverage.  I also don't see any explicit method coverage stats in the cobertura xml file.  How are you getting method coverage?  Are you getting it by looking at each method element in the report and generating those stats yourself?

    1. Dec 04, 2009

      David Carr says:

      Yes, I believe that the plug-in is doing its own aggregation of results.  T...

      Yes, I believe that the plug-in is doing its own aggregation of results.  This allows it to take multiple independent coverage.xml files and provide a single unified view of the coverage.

  21. Apr 22, 2010

    Peter Kreidermacher says:

    Hi, I've been running the cobertura plugin in Hudson for a couple of weeks now ...

    Hi,

    I've been running the cobertura plugin in Hudson for a couple of weeks now with no issues. All of a sudden, this morning, builds that were building correctly started failing. Looking in the console output it turns out that Hudson could not find the cobertura plugin. Nothing has changed as far as setup and configuration. I've tried disabling and enabling (with Hudson restarts) but cobertura is still not recognized by Hudson.

    Does anyone have any idea why this started to happen all of a sudden?

    Thanks!

  22. Apr 26, 2010

    Stuart Grimshaw says:

    There seem to be 2 styles of graph available from the Cobetura plugin, for proje...

    There seem to be 2 styles of graph available from the Cobetura plugin, for projects that have multiple Maven modules you get to see a trend over time, but if the project on has a single module, I get a bar chart that shows me the coverage for the last build.

    Is there any way to always display the trend graph?

  23. Oct 15, 2010

    Ravi Gairola says:

    I'm trying to get coverage Information across two modules, meaning one module (a...

    I'm trying to get coverage Information across two modules, meaning one module (a test module) is running tests on the other module.

    Unfortunately the cobertura plugin here doesn't consider cross module test coverage... or at least I haven't figured out how. I've already tried moving the configuration to the parent pom, but alas, no luck.

    Any ideas how this could be done?

    Thanks

  24. Jan 31, 2011

    Christian says:

    I saw that Cobertura also calculates the cyclomatic complexity of all classes, b...

    I saw that Cobertura also calculates the cyclomatic complexity of all classes, but in the Hudson Cobertura plugin this is not displayed anywhere. I had a look into the source code, it seems the corresponding XML attibute complexity is never evaluated by the plugin.

    Can you confirm this? Is support for displaying the cyclomatic complexity planned for the near future?

    Thanks in advance!

  25. Feb 11, 2011

    Alex Tang says:

    Is there any way to get at the cobertura data via the JSON (or any of the other)...

    Is there any way to get at the cobertura data via the JSON (or any of the other) Hudson remote apis?

    Thanks!

  26. Sep 20, 2011

    Arka Sharma says:

    Hi, I have created a simple maven project.Having only App.java under main>ja...

    Hi,

    I have created a simple maven project.Having only App.java under main>java>src and one AppTest.java under test>java>src.
    In App.java I have written a class called Calculator having add and substract method.In AppTest.java I have written testAdd and testSubstract.AppTest working fine when I run it through eclipse.Now I copied App.java and AppTest.java into the respective folder of my maven artifact.Now I run "mvn test" it shows "Build Successful"."Total test run 2".Now I have built the project in hudson.In the hudson build console same output is shown.Now I open up sonar and clicked on the sonar job to see the code coverage it shows

    Code coverage Test success
    - 0 tests
    I am not getting why it is showing 0 test success when both in maven and hudson it is showing total test run 2.And one more thing how to see the code coverage.Please help

    Regards,
    Arka

  27. Sep 20, 2011

    Arka Sharma says:

    After this I installed cobertura plug in in hudson.Then check the "Publish cover...

    After this I installed cobertura plug in in hudson.Then check the "Publish coverage report" inside the "Cobertura xml report pattern" text box i have entered "**/coverage.xml".I have changed in my pom.xml as following<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>cobertura-maven-plugin</artifactId>
    <version>2.2</version>
    <configuration>
    <formats>
    <format>xml</format>
    </formats>
    </configuration>
    <executions>
    <execution>
    <phase>package</phase>
    <goals>
    <goal>cobertura</goal>
    </goals>
    </execution>
    </executions>
    </plugin>
    I have not entered any thing in "Goals and Options" text box.Finally I ended up with
    "[DEBUG] Skipping watched dependency update for build: <Job Name> #1 due to result: FAILURE"
    Please any suggestion ?

    Regards,
    Arka

    Finished: FAILURE

    1. Sep 21, 2011

      Anton Kozak says:

      Hi Try to specify 2.5.1 cobertura-maven-plugin version and verify whether cover...

      Hi

      Try to specify 2.5.1 cobertura-maven-plugin version and verify whether coverage.xml was created in the workspace.