commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [parent][all] JaCoCo vs. Cobertura
Date Thu, 23 May 2013 04:53:11 GMT
On 5/22/13 5:45 PM, sebb wrote:
> On 23 May 2013 01:15, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Wed, May 22, 2013 at 7:43 PM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 22 May 2013 17:52, Gary Gregory <garydgregory@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message