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. 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.BOBYQAOptimizer</ignore> >>>> >> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore> >>>> >> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore> >>>> >> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore> >>>> </ignores> >>>> <excludes> >>>> >>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude> >>>> >>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude> >>>> </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
