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