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