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