On 23 May 2013 01:15, Gary Gregory <garydgreg...@gmail.com> wrote: > On Wed, May 22, 2013 at 7:43 PM, sebb <seb...@gmail.com> wrote: > >> On 22 May 2013 17:52, Gary Gregory <garydgreg...@gmail.com> wrote: >> > Hi All: >> > >> > [parent] version 29 replaces Cobertura with Jacoco, the main reasoning >> from >> > the folks over at [math] being that Jacoco is very fast compared to >> > Cobertura. In the case of [math] it's hours vs. minutes. >> > >> > The problem is that Jacoco produces bogus results as I recently emailed >> > about the [io] component. The large portion of the code is reported with >> 0% >> > coverage which is completely wrong. This is apparently a known issue due >> to >> > the Jacoco use of 'probes' to analyze code which is not compatible with >> the >> > use of exceptions. >> > >> > If you get the latest from [io] and edit the POM to enable JaCoC, you can >> > compare both reports in the generated site with 'mvn clean site'. >> > >> > Fast and bogus is not better than slow and right. >> > >> > I propose we switch [parent] back to Cobertura until a better alternative >> > is proposed. [math] can decide if it can live with the fast and bad >> results >> > provided by Jacoco. >> >> Why not include both as options, so components can choose? >> > > Sure, why not, it would be nice to be able to run both for the same report > set to see the differences.
As a test I created profiles for JaCoCo and Cobertura. These work fine when activated via the command-line. I had hoped to use a property defined in the component POM to enable the default coverage provider, unfortunately the profiles are resolved before the properties are defined. However file-based activation does work OK - this would require projects to define a dummy file somewhere, for example: src/site/resources/coverage.jacoco or src/site/resources/coverage.cobertura A component can thereby define the appropriate default coverage tool. This can be overridden on the command line, for example: -P!jacoco -Pcobertura > Gary > >> >> I'm currently experimenting with profiles to see if this can be done >> easily. >> >> > Gary >> > >> > -- >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> > Java Persistence with Hibernate, Second Edition< >> http://www.manning.com/bauer3/> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> > Spring Batch in Action <http://www.manning.com/templier/> >> > Blog: http://garygregory.wordpress.com >> > Home: http://garygregory.com/ >> > Tweet! http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
