You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/12/20 03:19:46 UTC
[Math] Request for future releases: kill Cobertura
Hello.
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?
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?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Request for future releases: kill Cobertura
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Thu, Dec 20, 2012 at 10:18:21AM +0100, Thomas Neidhart wrote:
> On Thu, Dec 20, 2012 at 3:19 AM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > Hello.
> >
> > 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?
> > 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?
> >
>
> Hi,
>
> The problem with the cobertura tests comes mainly from the performance
> tests for FastMath afaik.
Those are not automatically run (because the class name does not end with
"...Test").
The longest-running test is "BOBYQAOptimizerTest".
Regards,
Gilles
> We could disable them in the cobertura instrumentation (see
> http://mojo.codehaus.org/cobertura-maven-plugin/usage.html).
>
> The functions in question have separate accuracy tests, so the coverage
> should not be affected imho.
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Request for future releases: kill Cobertura
Posted by Thomas Neidhart <th...@gmail.com>.
On Thu, Dec 20, 2012 at 3:19 AM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> 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?
> 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?
>
Hi,
The problem with the cobertura tests comes mainly from the performance
tests for FastMath afaik.
We could disable them in the cobertura instrumentation (see
http://mojo.codehaus.org/cobertura-maven-plugin/usage.html).
The functions in question have separate accuracy tests, so the coverage
should not be affected imho.
Thomas
Re: [Math] Request for future releases: kill Cobertura
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Gilles,
2012/12/20 Gilles Sadowski <gi...@harfang.homelinux.org>
> Hello.
>
> 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?
> 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?
>
> Theoretically, yes [1]. However, when I run mvn site:site
-Dcobertura.skip=true, I get an error at the generation of the reports.
My config is
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.7.0_05
Java home: /usr/java/jdk1.7.0_05/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux" version: "3.6.9-2.fc17.x86_64" arch: "amd64" Family: "unix"
I also tested with maven 3
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /opt/apache-maven-3.0.4
Java version: 1.7.0_05, vendor: Oracle Corporation
Java home: /usr/java/jdk1.7.0_05/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "3.6.9-2.fc17.x86_64", arch: "amd64", family:
"unix"
and get the same error
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-cli) on
project commons-math3: failed to get report for
org.codehaus.mojo:cobertura-maven-plugin: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-test) on
project commons-math3: Error occurred in starting fork, check output in log
-> [Help 1]
This is probably a bug in the cobertura plugin, can anyone confirm?
A long time ago, I finally ended up killing --as you suggested-- the
cobertura lines in my local copy of the parent pom. This is uggly, but
works.
I don't know mvn well enough, but maybe we could define cobertura as
optional in the parent pom, and activate it by default in the parent. Would
that be doable (using properties)?
Sébastien
[1] http://mojo.codehaus.org/cobertura-maven-plugin/instrument-mojo.html
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Request for future releases: kill Cobertura
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/21 Phil Steitz <ph...@gmail.com>:
> On 12/21/12 10:53 AM, Sébastien Brisard wrote:
>> Hi,
>>
>>
>> 2012/12/21 Olivier Lamy <ol...@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?
>
This one is a bit special as it fork a lifecycle but due to the skip
option the forked lifecycle is not complete so the error below.
I don't have any workaround to prevent that.
So the best is to remove the plugin
> Looks like the plugin is definitely broken. I get this with the
> command-line option above:
>
> *[INFO] [cobertura:instrument {execution: default-instrument}]
> [INFO] Skipping cobertura execution
> [debug] execute contextualize
> [INFO] [resources:testResources {execution: default-testResources}]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 28 resources
> [INFO] Copying 2 resources to META-INF
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> /Users/psteitz/newMath/trunk/target/surefire-reports
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/math3/exception/DimensionMismatchException
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> at java.lang.Class.getMethod0(Class.java:2670)
>
>
> It is trying to needlessly execute the tests the second time as if
> it were generating the cobertura report.
>
> I really wish we could just drop this and the other reporting
> plugins from the parent and have components add the ones they want.
> In our [math] pom, we add configs for several of them anyway.
>
> Phil
> *
>>
>> Sébastien
>>
>> 2012/12/21 Phil Steitz <ph...@gmail.com>:
>>
>>>> On 12/20/12 1:25 PM, Olivier Lamy wrote:
>>>>> 2012/12/20 Luc Maisonobe <Lu...@free.fr>:
>>>>>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>>>>>> 2012/12/20 luc <lu...@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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Request for future releases: kill Cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/21/12 10:53 AM, Sébastien Brisard wrote:
> Hi,
>
>
> 2012/12/21 Olivier Lamy <ol...@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?
Looks like the plugin is definitely broken. I get this with the
command-line option above:
*[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Skipping cobertura execution
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 28 resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/Users/psteitz/newMath/trunk/target/surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/math3/exception/DimensionMismatchException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
It is trying to needlessly execute the tests the second time as if
it were generating the cobertura report.
I really wish we could just drop this and the other reporting
plugins from the parent and have components add the ones they want.
In our [math] pom, we add configs for several of them anyway.
Phil
*
>
> Sébastien
>
> 2012/12/21 Phil Steitz <ph...@gmail.com>:
>
>>> On 12/20/12 1:25 PM, Olivier Lamy wrote:
>>>> 2012/12/20 Luc Maisonobe <Lu...@free.fr>:
>>>>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>>>>> 2012/12/20 luc <lu...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Request for future releases: kill Cobertura
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
2012/12/21 Olivier Lamy <ol...@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 <ph...@gmail.com>:
> > On 12/20/12 1:25 PM, Olivier Lamy wrote:
> >> 2012/12/20 Luc Maisonobe <Lu...@free.fr>:
> >>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
> >>>> 2012/12/20 luc <lu...@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
>
>
Re: [Math] Request for future releases: kill Cobertura
Posted by Olivier Lamy <ol...@apache.org>.
-Dcobertura.skip=true ?
or in pom.properties
<cobertura.skip>true</cobertura.skip>
2012/12/21 Phil Steitz <ph...@gmail.com>:
> On 12/20/12 1:25 PM, Olivier Lamy wrote:
>> 2012/12/20 Luc Maisonobe <Lu...@free.fr>:
>>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>>> 2012/12/20 luc <lu...@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<de...@commons.apache.org>
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@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
Re: [Math] Request for future releases: kill Cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/20/12 1:25 PM, Olivier Lamy wrote:
> 2012/12/20 Luc Maisonobe <Lu...@free.fr>:
>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>> 2012/12/20 luc <lu...@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<de...@commons.apache.org>
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------**------------------------------**---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@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
Re: [Math] Request for future releases: kill Cobertura
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/20 Luc Maisonobe <Lu...@free.fr>:
> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>> 2012/12/20 luc <lu...@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<de...@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@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
Re: [Math] Request for future releases: kill Cobertura
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 20/12/2012 18:05, Benedikt Ritter a écrit :
> 2012/12/20 luc <lu...@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!
Luc
>
> Benedikt
>
>
>
>>
>> best regards,
>> Luc
>>
>>
>>
>>> Phil
>>>
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@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
Re: [Math] Request for future releases: kill Cobertura
Posted by Benedikt Ritter <be...@gmail.com>.
2012/12/20 luc <lu...@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<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Request for future releases: kill Cobertura
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Luc,
2012/12/20 luc <lu...@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
Re: [Math] Request for future releases: kill Cobertura
Posted by luc <lu...@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.
best regards,
Luc
>
> Phil
>>
>>
>> Regards,
>> Gilles
>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Request for future releases: kill Cobertura
Posted by Phil Steitz <ph...@gmail.com>.
On 12/19/12 6:19 PM, Gilles Sadowski wrote:
> Hello.
>
> 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.
Phil
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Request for future releases: kill Cobertura
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/20 Benedikt Ritter <be...@gmail.com>:
> 2012/12/20 Olivier Lamy <ol...@apache.org>
>
>> 2012/12/20 Benedikt Ritter <be...@gmail.com>:
>> > What about a sonar instance for commons?
>>
>> I have discussed this on an other thread.
>> FYI I have just added 4 sub projects. Result here
>> https://analysis.apache.org/components/index/121254
>
>
> Yes, I was thinking about your post :-)
> I don't know Sonar very well. What exactly is it monitoring? The trunk?
> Is there a possibility to add reporting for release tags?
only trunk currently.
>
> Benedikt
>
>
>>
>>
>> It's just a matter of adding more in this pom:
>> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml
>>
>> >
>> > Benedikt
>>
>>
>>
>> --
>> 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
>>
>>
--
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
Re: [Math] Request for future releases: kill Cobertura
Posted by Benedikt Ritter <be...@gmail.com>.
2012/12/20 Olivier Lamy <ol...@apache.org>
> 2012/12/20 Benedikt Ritter <be...@gmail.com>:
> > What about a sonar instance for commons?
>
> I have discussed this on an other thread.
> FYI I have just added 4 sub projects. Result here
> https://analysis.apache.org/components/index/121254
Yes, I was thinking about your post :-)
I don't know Sonar very well. What exactly is it monitoring? The trunk?
Is there a possibility to add reporting for release tags?
Benedikt
>
>
> It's just a matter of adding more in this pom:
> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml
>
> >
> > Benedikt
>
>
>
> --
> 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
>
>
Re: [Math] Request for future releases: kill Cobertura
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Thu, Dec 20, 2012 at 09:46:56AM +0100, Olivier Lamy wrote:
> 2012/12/20 Benedikt Ritter <be...@gmail.com>:
> > What about a sonar instance for commons?
>
> I have discussed this on an other thread.
> FYI I have just added 4 sub projects. Result here
> https://analysis.apache.org/components/index/121254
>
> It's just a matter of adding more in this pom:
> http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml
Yes; thanks for the proposal.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Request for future releases: kill Cobertura
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/20 Benedikt Ritter <be...@gmail.com>:
> What about a sonar instance for commons?
I have discussed this on an other thread.
FYI I have just added 4 sub projects. Result here
https://analysis.apache.org/components/index/121254
It's just a matter of adding more in this pom:
http://svn.apache.org/repos/asf/commons/trunks-proper/pom.xml
>
> Benedikt
--
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
Re: [Math] Request for future releases: kill Cobertura
Posted by Benedikt Ritter <be...@gmail.com>.
What about a sonar instance for commons?
Benedikt
Re: [Math] Request for future releases: kill Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
Also, is it faster with Clover or Emma? We have an ASF license for Clover.
Gary
On Wed, Dec 19, 2012 at 9:26 PM, Gary Gregory <ga...@gmail.com>wrote:
> I do not think skipping should be done at the parent level. If [math]
> wants to skip it, it can.
>
> Gary
>
>
> On Wed, Dec 19, 2012 at 9:19 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> Hello.
>>
>> 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?
>> 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?
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [Math] Request for future releases: kill Cobertura
Posted by Gary Gregory <ga...@gmail.com>.
I do not think skipping should be done at the parent level. If [math] wants
to skip it, it can.
Gary
On Wed, Dec 19, 2012 at 9:19 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> 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?
> 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?
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory