On 23 May 2013 05:53, Phil Steitz <phil.ste...@gmail.com> wrote: > 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 :)
That's equivalent to what I was proposing. The profiles would be optional. The idea of having it in the parent pom is to reduce the work in maintaining child poms, and make it simpler to switch between plugins (or indeed run both or neither). Common code and all that. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
