commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [Math] Request for future releases: kill Cobertura
Date Fri, 21 Dec 2012 18:53:44 GMT
Hi,


2012/12/21 Olivier Lamy <olamy@apache.org>

> -Dcobertura.skip=true ?
> or in pom.properties
> <cobertura.skip>true</cobertura.skip>
>
> I agree with Phil, both options lead to strange error messages (see my
post above). Should it be considered as a bug of the cobertura plugin?

Sébastien

2012/12/21 Phil Steitz <phil.steitz@gmail.com>:

> > On 12/20/12 1:25 PM, Olivier Lamy wrote:
> >> 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
> >
> > Thanks!
> >
> > Now can we either dump coberta from commons parent or can someone
> > indicate a way that actually works to turn it off?  I can't get any
> > of the tricks mentioned so far to work.  I get strange errors when I
> > try to either configure the skip parameter for it in the component
> > pom or use the command line.
> >
> > Phil
> >>
> >>
> >>> 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
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message