On 5/22/13 5:45 PM, sebb wrote: > 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
Why not just let projects add a coverage reporting plugin if they want it? I think that is how maven is designed to work :) Phil > >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
