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.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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
