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.
best regards,
Luc
Phil
Regards,
Gilles
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
