You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2013/05/22 18:52:33 UTC
[parent][all] JaCoCo vs. Cobertura
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.
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 5/22/13 9:52 AM, Gary Gregory 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.
Maybe broken-record-ish, but I really, really think there should be
*nothing* forced by the parent here - i.e., let the individual
components decide which, if either one, to use.
Phil
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, May 23, 2013 at 3:49 AM, sebb <se...@gmail.com> wrote:
> On 23 May 2013 08:34, Jörg Schaible <Jo...@scalaris.com> wrote:
> > Hi Sebb,
> >
> > sebb wrote:
> >
> > [snip]
> >
> >> 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
> >
> > if we start to get into the file-based profile activation, I strongly
> > suggest to follow a common pattern and use a profile directory:
> >
> > =========== %< =============
> > pom.xml
> > profiles/
> > cobertura
> > =========== %< =============
> >
> > Otherwise no-one knows in the end what file triggers an automated
> profile.
>
> I choose src/site/resources because the profiles affect the site build
> and I did not want to create a new folder.
>
> But of course other locations are possible.
>
> Or we could use "profile.jacoco" instead of "coverage.jacoco" under
> src/site/resources
>
> I have committed the change as originally proposed.
> We can change the trigger files (and associated comments) before releasing
> CP30
>
> Meanwhile please try out the new profiles.
>
I like the file-based approach better than using the command line, so I
used that in [codec] locally and was able to selectively run one coverage
tool and then both.
So it's good by me.
Gary
>
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by sebb <se...@gmail.com>.
On 23 May 2013 08:34, Jörg Schaible <Jo...@scalaris.com> wrote:
> Hi Sebb,
>
> sebb wrote:
>
> [snip]
>
>> 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
>
> if we start to get into the file-based profile activation, I strongly
> suggest to follow a common pattern and use a profile directory:
>
> =========== %< =============
> pom.xml
> profiles/
> cobertura
> =========== %< =============
>
> Otherwise no-one knows in the end what file triggers an automated profile.
I choose src/site/resources because the profiles affect the site build
and I did not want to create a new folder.
But of course other locations are possible.
Or we could use "profile.jacoco" instead of "coverage.jacoco" under
src/site/resources
I have committed the change as originally proposed.
We can change the trigger files (and associated comments) before releasing CP30
Meanwhile please try out the new profiles.
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Sebb,
sebb wrote:
[snip]
> 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
if we start to get into the file-based profile activation, I strongly
suggest to follow a common pattern and use a profile directory:
=========== %< =============
pom.xml
profiles/
cobertura
=========== %< =============
Otherwise no-one knows in the end what file triggers an automated profile.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [parent][all] JaCoCo vs. Cobertura
Posted by sebb <se...@gmail.com>.
On 23 May 2013 05:53, Phil Steitz <ph...@gmail.com> wrote:
> On 5/22/13 5:45 PM, sebb wrote:
>> On 23 May 2013 01:15, Gary Gregory <ga...@gmail.com> wrote:
>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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: 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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 26/05/2013 23:38, Gary Gregory a écrit :
> So are we ready for a release 30?
I guess so.
Luc
>
> Gary
>
>
> On Sat, May 25, 2013 at 1:03 PM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Hi all,
>>
>> Le 23/05/2013 20:55, Luc Maisonobe a écrit :
>>> Le 23/05/2013 20:52, Gary Gregory a écrit :
>>>> I think all this is addressed by the parent POM in trunk. Please check
>> it
>>>> out for [math] and we can then talk about getting a version 30 out the
>> door.
>>>
>>> Sure. I'll look at it probably tomorrow. I am quite tired this evening.
>>
>> I have checked commons parent 30-SNAPSHOT.
>>
>> It works great, thanks.
>>
>> Luc
>>
>>>
>>> Luc
>>>
>>>>
>>>> Gary
>>>>
>>>>
>>>> On Thu, May 23, 2013 at 2:38 PM, 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 <ga...@gmail.com> wrote:
>>>>>>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
So are we ready for a release 30?
Gary
On Sat, May 25, 2013 at 1:03 PM, Luc Maisonobe <Lu...@free.fr>wrote:
> Hi all,
>
> Le 23/05/2013 20:55, Luc Maisonobe a écrit :
> > Le 23/05/2013 20:52, Gary Gregory a écrit :
> >> I think all this is addressed by the parent POM in trunk. Please check
> it
> >> out for [math] and we can then talk about getting a version 30 out the
> door.
> >
> > Sure. I'll look at it probably tomorrow. I am quite tired this evening.
>
> I have checked commons parent 30-SNAPSHOT.
>
> It works great, thanks.
>
> Luc
>
> >
> > Luc
> >
> >>
> >> Gary
> >>
> >>
> >> On Thu, May 23, 2013 at 2:38 PM, 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 <ga...@gmail.com> wrote:
> >>>>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
> >>>>>>
> >>>>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
> >>>
> >>>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi all,
Le 23/05/2013 20:55, Luc Maisonobe a écrit :
> Le 23/05/2013 20:52, Gary Gregory a écrit :
>> I think all this is addressed by the parent POM in trunk. Please check it
>> out for [math] and we can then talk about getting a version 30 out the door.
>
> Sure. I'll look at it probably tomorrow. I am quite tired this evening.
I have checked commons parent 30-SNAPSHOT.
It works great, thanks.
Luc
>
> Luc
>
>>
>> Gary
>>
>>
>> On Thu, May 23, 2013 at 2:38 PM, Luc Maisonobe <Lu...@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 <ga...@gmail.com> wrote:
>>>>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 23/05/2013 20:52, Gary Gregory a écrit :
> I think all this is addressed by the parent POM in trunk. Please check it
> out for [math] and we can then talk about getting a version 30 out the door.
Sure. I'll look at it probably tomorrow. I am quite tired this evening.
Luc
>
> Gary
>
>
> On Thu, May 23, 2013 at 2:38 PM, Luc Maisonobe <Lu...@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 <ga...@gmail.com> wrote:
>>>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
I think all this is addressed by the parent POM in trunk. Please check it
out for [math] and we can then talk about getting a version 30 out the door.
Gary
On Thu, May 23, 2013 at 2:38 PM, Luc Maisonobe <Lu...@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 <ga...@gmail.com> wrote:
> >>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
>
>
--
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by sebb <se...@gmail.com>.
On 23 May 2013 19:38, Luc Maisonobe <Lu...@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 <ga...@gmail.com> wrote:
>>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
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 <ga...@gmail.com> wrote:
>>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 5/22/13 5:45 PM, sebb wrote:
> On 23 May 2013 01:15, Gary Gregory <ga...@gmail.com> wrote:
>> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 22 May 2013 17:52, Gary Gregory <ga...@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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by sebb <se...@gmail.com>.
On 23 May 2013 01:15, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
>
>> On 22 May 2013 17:52, Gary Gregory <ga...@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
> 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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 22, 2013 at 7:43 PM, sebb <se...@gmail.com> wrote:
> On 22 May 2013 17:52, Gary Gregory <ga...@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.
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by sebb <se...@gmail.com>.
On 22 May 2013 17:52, Gary Gregory <ga...@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?
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 22, 2013 at 12:58 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 22/05/2013 18:52, Gary Gregory a écrit :
>
> > 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.
>
> What do you mean by probe? It doesn't instrument the code?
>
>From http://www.eclemma.org/faq.html#trouble02:
"Code with exceptions shows no coverage. Why?
The underlying JaCoCo code coverage library works with so called probes.
Probes are inserted into the control flow at certain positions. Code is
considered as executed when a subsequent probe has been executed. In case
of exceptions such a sequence of instructions is aborted somewhere in the
middle and not marked as executed."
Gary
>
>
> Emmanuel Bourg
>
>
>
--
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
Re: [parent][all] JaCoCo vs. Cobertura
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 22/05/2013 18:52, Gary Gregory a écrit :
> 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.
What do you mean by probe? It doesn't instrument the code?
Emmanuel Bourg