commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: [Math] Request for future releases: kill Cobertura
Date Thu, 20 Dec 2012 21:25:00 GMT
2012/12/20 Luc Maisonobe <Luc.Maisonobe@free.fr>:
> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>> 2012/12/20 luc <luc@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-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message