Hi,
2012/12/21 Olivier Lamy <ol...@apache.org> > -Dcobertura.skip=true ? > or in pom.properties > <cobertura.skip>true</cobertura.skip> > > I agree with Phil, both options lead to strange error messages (see my post above). Should it be considered as a bug of the cobertura plugin? Sébastien 2012/12/21 Phil Steitz <phil.ste...@gmail.com>: > > On 12/20/12 1:25 PM, Olivier Lamy wrote: > >> 2012/12/20 Luc Maisonobe <luc.maison...@free.fr>: > >>> Le 20/12/2012 18:05, Benedikt Ritter a écrit : > >>>> 2012/12/20 luc <l...@spaceroots.org> > >>>> > >>>>> Le 2012-12-20 15:01, Phil Steitz a écrit : > >>>>> > >>>>> On 12/19/12 6:19 PM, Gilles Sadowski wrote: > >>>>>>> Hello. > >>>>>>> > >>>>> Hi all, > >>>>> > >>>>> > >>>>> > >>>>>>> The situation with "Cobertura" is fairly annoying, perhaps > particularly > >>>>>>> so > >>>>>>> for Commons Math because of the size of the code base (and thus the > >>>>>>> fairly > >>>>>>> large number of unit tests). > >>>>>>> > >>>>>>> As it just happened, a few minor problems have now delayed the > release by > >>>>>>> several days because I have to wait about 4 hours for the site > generation > >>>>>>> to complete (on a _fast_ machine). > >>>>>>> Hence the request to remove Cobertura from the "site" target, or > at least > >>>>>>> from the "site:stage-deploy" step, so that a new vote can take > place as > >>>>>>> soon > >>>>>>> as a problem is fixed. > >>>>>>> [I would even argue that it is not that useful to include > Cobertura in > >>>>>>> the > >>>>>>> release process because the amount of code coverage is not acted > upon > >>>>>>> (i.e. > >>>>>>> low coverage would not block a release IIUC).] > >>>>>>> > >>>>>>> Do you agree? > >>>>>>> > >>>>>> +1 > >>>>>> > >>>>>>> If so, can we change that for Commons Math only, or should this be > done > >>>>>>> at > >>>>>>> the "parent" level? Is is just a matter of adding > >>>>>>> <cobertura.skip>true</**cobertura.skip> > >>>>>>> in a new profile? > >>>>>>> > >>>>>> This is an argument that we have from time to time. IMO the parent > >>>>>> should contain a minimal set of plugins and component POMs should > >>>>>> explicitly include the ones they want. I would be +1 for dropping > >>>>>> Coberta from the parent pom. > >>>>>> > >>>>> I will play devils advocate. Cobertura is really useful and provides > useful > >>>>> information. It also clearly help popularizing [math] as we can > prove it is > >>>>> a well tested component. So I don't agree removing it totally. > >>>>> > >>>>> However, I agree it has become really annoying mainly due to its > very poor > >>>>> performances with respect to Bobyqa tests. It really takes hours to > perform > >>>>> all site generation. Gilles spoke about 4 hours on a fast machine, > but my > >>>>> home computer is not fast and it takes much longer to me. When I > want to do > >>>>> a full generation, I let it run overnight. > >>>>> > >>>>> So if another mean to have the same information is available (or to > make > >>>>> cobertura run faster, especially for the bobyqa test), then I would > >>>>> be glad to drop cobertura. If there are no other means, I would not > be > >>>>> glad. > >>>>> > >>>>> I would prefer than the output from the test coverage would end up > in the > >>>>> public > >>>>> site. Even if only the current trunk is covered, that would be > sufficient > >>>>> for > >>>>> my needs, so if some existing continuous integration system can be > set up, > >>>>> I'm > >>>>> fine with that. Note that we really need to get information down to > line > >>>>> of code > >>>>> level, as it is the only way we can extend tests. The cobertura > report is > >>>>> really > >>>>> nice for that as it directly provides colored versions of the source > code > >>>>> which > >>>>> are really easy to use for the developer. > >>>>> > >>>> Hi Luc, > >>> Hi Benedikt, > >>> > >>>> have a look at the test installation Oliver has set up: > >>>> https://analysis.apache.org/components/index/121254, for example > have a > >>>> look at the org.apache.commons.lang3.builder package: > >>>> https://analysis.apache.org/components/index/121815 > >>>> If you click on one of the magnifying glasses on the right side, you > get a > >>>> detailed view of a particular class. Click on the Coverage tab in the > top > >>>> right side and you will have the coverage displayed like in Cobertura. > >>> Thank you very much for the link. > >>> This report is really useful, and provides even more hindsight thant > the > >>> cobertura one. > >>> > >>> So a big +1 to heve it enabled for [math] replacing cobertura! > >> Done check here https://analysis.apache.org/dashboard/index/122571 > >> > >> De rien :-) > >> > >> Note: to add more projects just a <module> in this pom > >> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml > >> > >> Daily in case of any scm changes in path > >> http://svn.apache.org/repos/asf/commons/trunks-proper/ report are > >> rebuild. > >> > >> Note: Sonar use jacoco and not cobertura. > >> Some details on differences here: > >> > http://www.dzone.com/links/r/code_coverage_tools_jacoco_cobertura_emma_compari.html > > > > Thanks! > > > > Now can we either dump coberta from commons parent or can someone > > indicate a way that actually works to turn it off? I can't get any > > of the tricks mentioned so far to work. I get strange errors when I > > try to either configure the skip parameter for it in the component > > pom or use the command line. > > > > Phil > >> > >> > >>> Luc > >>> > >>> > >>>> Benedikt > >>>> > >>>> > >>>> > >>>>> best regards, > >>>>> Luc > >>>>> > >>>>> > >>>>> > >>>>>> Phil > >>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> Gilles > >>>>>>> > >>>>>>> > >>>>>>> ------------------------------**------------------------------** > >>>>>>> --------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org< > dev-unsubscr...@commons.apache.org> > >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > ------------------------------**------------------------------**--------- > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org< > dev-unsubscr...@commons.apache.org> > >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>> > >>>>> > >>>>> > ------------------------------**------------------------------**--------- > >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org< > 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 > >>> > >> > >> > >> -- > >> Olivier Lamy > >> Talend: http://coders.talend.com > >> http://twitter.com/olamy | http://linkedin.com/in/olamy > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >