Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: error (athena.apache.org: local policy)
Message-ID: <519E6223.10300@free.fr>
Date: Thu, 23 May 2013 20:38:27 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:10.0.12) Gecko/20130116 Icedove/10.0.12
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [parent][all] JaCoCo vs. Cobertura
References: 
 <CACZkXPzN1qn0R3REq-mu7MoPqV+=KWnZv+DQi64PZ7hWf4o1NA@mail.gmail.com>
 <CAOGo0VYavjyWVqyu++Wt6SSV96wGoAYM1pt9WMn-1ayhhTMb=A@mail.gmail.com>
 <CACZkXPzjhi3sW7fNMWkJOL=5ojXGq7bCRAcVDNm2JR-X8M1KuQ@mail.gmail.com>
 <CAOGo0VbZU9O+zyZf5GgqoKnJw4y8JQmjzYLz0Aho8UKtbpk1sQ@mail.gmail.com>
 <519DA0B7.7090304@gmail.com>
In-Reply-To: <519DA0B7.7090304@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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, 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.

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