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