Hi Luc,
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. > > If bobyqa is the main culprit, maybe we could exclude it from the coverage report [1]. From what I understand, the current implementation of BOBYQA does not reach our standards anyway... We could at least define a profile in which the most critical classes are excluded. People who currently work on these classes can include them in the coverage report on demand, and the whole set of classes is included only to generate the online website. > 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. > > I think we all agree that this is a very useful report. However, it currently takes so long to generate that I totally disabled it (and I suspect others, too...). Sébastien > best regards, > Luc > > [1] http://mojo.codehaus.org/cobertura-maven-plugin/usage.html#Instrumentation
