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.
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 > > -- 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
