commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [parent][all] JaCoCo vs. Cobertura
Date Thu, 23 May 2013 18:50:33 GMT
On 23 May 2013 19:38, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> Le 23/05/2013 06:53, Phil Steitz a écrit :
>> 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.
>
> It's not the only problem.
> The other two problems we encountered are:
>
>  - there are bugs in cobertura that generates errors (typically when
>    using floating numbers with hexadecimal encoding, which is very
>    important for some specific constants representing specific numbers
>    in IEEE encoding)
>  - cobertura CANNOT be switched off when in parent pom. All normal
>    means to to prevent it completely failed up to now. So we could not
>    live with the current pom
>
>>>>>>
>>>>>> 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.
>
> Strong -1 to bring cobertura back to parent unless it can *really* be
> switched off, which was not the case with parent 28 and earlier.
>
> If it can be switched off, then yes, this makes sense.
>
>>>>> 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 :)
>
> This would be a good solution.
>
> In fact when I replaced cobertura with jacoco, my intend was much more
> to remove cobertura than impose jacoco.
>
> The previous discussion we had seemed to show that we did want a shared
> coverage tool, but cobertura was really a problem. Now we find that
> Jacoco also has some major drawbacks, so I guess the proper way is to
> forget the idea of a shared tool and let components choose their own
> way. So either we find a *real* way to prevent one from running and use
> the other,

The current CP 30-SNAPSHOT does this.

> or we don't put anything at parent level and let components
> do this. Both solutions are equivalent to me until we find a third tool,
> a fourth tool ... in which case handling all possibilities in the parent
> pom becomes cumbersome and handling this at component level seems to
> remain manageable.

Let's wait and see if there really is another tool that is sometimes
better than either JaCoCo or Cobertura and sometimes worse, and then
decide.

> best regards,
> Luc
>
>>
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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