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