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 <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
