2012/12/21 Phil Steitz <phil.ste...@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 <phil.ste...@gmail.com>:
>>
>>>> On 12/20/12 1:25 PM, Olivier Lamy wrote:
>>>>> 2012/12/20 Luc Maisonobe <luc.maison...@free.fr>:
>>>>>> Le 20/12/2012 18:05, Benedikt Ritter a écrit :
>>>>>>> 2012/12/20 luc <l...@spaceroots.org>
>>>>>>>
>>>>>>>> Le 2012-12-20 15:01, Phil Steitz a écrit :
>>>>>>>>
>>>>>>>> On 12/19/12 6:19 PM, Gilles Sadowski wrote:
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> The situation with "Cobertura" is fairly annoying, perhaps
>>> particularly
>>>>>>>>>> so
>>>>>>>>>> for Commons Math because of the size of the code base (and thus the
>>>>>>>>>> fairly
>>>>>>>>>> large number of unit tests).
>>>>>>>>>>
>>>>>>>>>> As it just happened, a few minor problems have now delayed the
>>> release by
>>>>>>>>>> several days because I have to wait about 4 hours for the site
>>> generation
>>>>>>>>>> to complete (on a _fast_ machine).
>>>>>>>>>> Hence the request to remove Cobertura from the "site" target, or
>>> at least
>>>>>>>>>> from the "site:stage-deploy" step, so that a new vote can take
>>> place as
>>>>>>>>>> soon
>>>>>>>>>> as a problem is fixed.
>>>>>>>>>> [I would even argue that it is not that useful to include
>>> Cobertura in
>>>>>>>>>> the
>>>>>>>>>> release process because the amount of code coverage is not acted
>>> upon
>>>>>>>>>> (i.e.
>>>>>>>>>> low coverage would not block a release IIUC).]
>>>>>>>>>>
>>>>>>>>>> Do you agree?
>>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> If so, can we change that for Commons Math only, or should this be
>>> done
>>>>>>>>>> at
>>>>>>>>>> the "parent" level? Is is just a matter of adding
>>>>>>>>>> <cobertura.skip>true</**cobertura.skip>
>>>>>>>>>> in a new profile?
>>>>>>>>>>
>>>>>>>>> This is an argument that we have from time to time. IMO the parent
>>>>>>>>> should contain a minimal set of plugins and component POMs should
>>>>>>>>> explicitly include the ones they want. I would be +1 for dropping
>>>>>>>>> Coberta from the parent pom.
>>>>>>>>>
>>>>>>>> I will play devils advocate. Cobertura is really useful and provides
>>> useful
>>>>>>>> information. It also clearly help popularizing [math] as we can
>>> prove it is
>>>>>>>> a well tested component. So I don't agree removing it totally.
>>>>>>>>
>>>>>>>> However, I agree it has become really annoying mainly due to its
>>> very poor
>>>>>>>> performances with respect to Bobyqa tests. It really takes hours to
>>> perform
>>>>>>>> all site generation. Gilles spoke about 4 hours on a fast machine,
>>> but my
>>>>>>>> home computer is not fast and it takes much longer to me. When I
>>> want to do
>>>>>>>> a full generation, I let it run overnight.
>>>>>>>>
>>>>>>>> So if another mean to have the same information is available (or to
>>> make
>>>>>>>> cobertura run faster, especially for the bobyqa test), then I would
>>>>>>>> be glad to drop cobertura. If there are no other means, I would not
>>> be
>>>>>>>> glad.
>>>>>>>>
>>>>>>>> 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-unsubscr...@commons.apache.org>
>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<
>>> dev-unsubscr...@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>
>>>>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<
>>> dev-unsubscr...@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
