I have been experimenting with jacoco in the ClassScan sandbox. I am impressed with how easy jacoco is to setup and run. Although published benchmarks show jacoco and cobertura having roughly equivalent performance impact, the maven-cobertura-plugin has a twist that makes cobertura much slower:
The cobertura plugin re-runs the unit tests in order to capture the coverage statistics; this doubles the time taken for unit tests. Jacoco, on the other hand, does not need to create separate instrumented class files, and will collect statistics on the unit tests run during the test phase. Additionally, you don't have to run a site cycle to get the report; usually it's attached to the verify phase. I recommend that we make jacoco the default code coverage tool in the parent pom, with a commons.jacoco.skip property which will cause turn code coverage off. Another interesting speed up is in the surefire-report plugin. Again, by default, this plugin re-runs the unit tests! If we change the configuration to use the report-only goal, the unit tests will not be re-run during the site cycle. This does mean you must run the build cycle before running the site cycle. I'm not sure this is a problem; I've never been able to get any reasonable sized project to run the site cycle separately. Regards, chas On 3/25/13 11:12 AM, "sebb" <seb...@gmail.com> wrote: >On 25 March 2013 17:48, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 3/25/13 9:08 AM, Gary Gregory wrote: >>> Replacing one test coverage plugin in the parent POM with another is >>> probably OK, but must be tested. >>> >>> But if someone decides to remove this test coverage plugin from the >>>parent >>> POM, then make sure to enable it is all the other components. >> >> Why? The thing is *broken* and not maintained. Why not just get >> rid of it and let components decide if they want to add it back or >> replace it with something else? I get the point of commons-parent >> for things like mailing list, download pages, etc; but reporting >> plugins should be chosen by the components, not forced by the parent >> pom. > >+1 > >However, if the setting can be done in a profile, and the profile can >be enabled by setting a property in the component POM, that might be >worthwhil. > >There are some reports that we want to appear in all components; those >should remain in the parent POM. > >> Phil >>> >>> Gary >>> >>> >>> On Mon, Mar 25, 2013 at 11:34 AM, Phil Steitz <phil.ste...@gmail.com> >>>wrote: >>> >>>> On 3/25/13 8:12 AM, Emmanuel Bourg wrote: >>>>> Is it possible to disable cobertura at the component level only? >>>> The short answer is no. Its bugged-ness extends to ignoring the >>>> disabling config. >>>> >>>> Phil >>>>> >>>>> Emmanuel Bourg >>>>> >>>>> >>>>> Le 25/03/2013 11:01, Luc Maisonobe a écrit : >>>>>> Hi all, >>>>>> >>>>>> We have already discussed about some problems with the cobertura >>>>>>maven >>>>>> plugin (see <http://markmail.org/thread/hqckkacin7zby35c> and >>>>>> <http://markmail.org/thread/7xecuq6shtc4vkzy>). >>>>>> >>>>>> As a summary, cobertura seems to not be maintained, there are some >>>>>>bugs >>>>>> that trigger errors with [math] (see for example >>>>>> < >>>> >>>>http://sourceforge.net/tracker/?func=detail&aid=3089579&group_id=130558 >>>>&atid=720015 >>>>> ), >>>>>> it takes ages on some tests: on my machine, which is not really >>>>>>fast, it >>>>>> takes about 9 hours to run [math]! >>>>>> >>>>>> As suggested in the threads above, I have tried to remove >>>>>> instrumentation for the too long BOBYQA tests using this: >>>>>> >>>>>> <plugin> >>>>>> <groupId>org.codehaus.mojo</groupId> >>>>>> <artifactId>cobertura-maven-plugin</artifactId> >>>>>> <version>${commons.cobertura.version}</version> >>>>>> <configuration> >>>>>> <instrumentation> >>>>>> <ignores> >>>>>> >>>>>> >>>> >>>><ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAO >>>>ptimizer</ignore> >>>>>> >>>> >>>><ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAO >>>>ptimizerTest</ignore> >>>>>> >>>> >>>><ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</i >>>>gnore> >>>>>> >>>> >>>><ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTes >>>>t</ignore> >>>>>> </ignores> >>>>>> <excludes> >>>>>> >>>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude> >>>>>> >>>>>> >>>>>><exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclu >>>>>>de> >>>>>> </excludes> >>>>>> </instrumentation> >>>>>> </configuration> >>>>>> </plugin> >>>>>> >>>>>> It failed, the tests are still take ages to run. I tried to add the >>>>>> previous setting in either build or report sections, none worked. >>>>>> >>>>>> It therefore appear there is nothing we can do at [math] level to >>>>>> prevent this, despite the offending tests do run properly in many >>>>>>cases >>>>>> outside of cobertura (there are random errors with exceeded >>>>>>iteration >>>>>> count from time to time). >>>>>> >>>>>> As we are heading to publish [math] 3.2, it is a very huge problem >>>>>>for >>>>>> us. It already was for 3.1.1, and it will be as long as we don't >>>>>>remove >>>>>> cobertura. >>>>>> >>>>>> As shown with the sonar instance, Jacoco does a fairly good job at >>>>>> computing coverage.However, it seems it is not as well integrated >>>>>>into >>>>>> maven reports as cobertura. In another project, I had to set up a >>>>>>custom >>>>>> entry in the menu to point to the generated pages in the site menu. >>>>>> >>>>>> Would it be possible to replace cobertura with jacoco in parent pom, >>>>>> either with a manual link to the generated page or with a proper >>>>>> integration with other reports? >>>>>> >>>>>> best regards, >>>>>> Luc >>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
