commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [parent][all] JaCoCo vs. Cobertura
Date Thu, 23 May 2013 18:52:48 GMT
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 <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, 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message