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.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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
