On 23 May 2013 19:38, Luc Maisonobe <luc.maison...@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 <garydgreg...@gmail.com> wrote: >>>> On Wed, May 22, 2013 at 7:43 PM, sebb <seb...@gmail.com> wrote: >>>> >>>>> On 22 May 2013 17:52, Gary Gregory <garydgreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
