So are we ready for a release 30? 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 > > -- 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
