commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <Charles_Hon...@intuit.com>
Subject Re: [all] replacing cobertura with jacoco in parent pom
Date Sat, 30 Mar 2013 22:29:38 GMT
I have been experimenting with jacoco in the ClassScan sandbox.  I am
impressed with how easy jacoco is to setup and run.  Although published
benchmarks show jacoco and cobertura having roughly equivalent performance
impact, the maven-cobertura-plugin has a twist that makes cobertura much
slower:

The cobertura plugin re-runs the unit tests in order to capture the
coverage statistics; this doubles the time taken for unit tests.  Jacoco,
on the other hand, does not need to create separate instrumented class
files, and will collect statistics on the unit tests run during the test
phase.  Additionally, you don't have to run a site cycle to get the
report; usually it's attached to the verify phase.

I recommend that we make jacoco the default code coverage tool in the
parent pom, with a commons.jacoco.skip property which will cause turn code
coverage off.

Another interesting speed up is in the surefire-report plugin.  Again, by
default, this plugin re-runs the unit tests!  If we change the
configuration to use the report-only goal, the unit tests will not be
re-run during the site cycle.  This does mean you must run the build cycle
before running the site cycle.  I'm not sure this is a problem; I've never
been able to get any reasonable sized project to run the site cycle
separately.

Regards,
chas



On 3/25/13 11:12 AM, "sebb" <sebbaz@gmail.com> wrote:

>On 25 March 2013 17:48, Phil Steitz <phil.steitz@gmail.com> wrote:
>> On 3/25/13 9:08 AM, Gary Gregory wrote:
>>> Replacing one test coverage plugin in the parent POM with another is
>>> probably OK, but must be tested.
>>>
>>> But if someone decides to remove this test coverage plugin from the
>>>parent
>>> POM, then make sure to enable it is all the other components.
>>
>> Why?  The thing is *broken* and not maintained.  Why not just get
>> rid of it and let components decide if they want to add it back or
>> replace it with something else?  I get the point of commons-parent
>> for things like mailing list, download pages, etc; but reporting
>> plugins should be chosen by the components, not forced by the parent
>> pom.
>
>+1
>
>However, if the setting can be done in a profile, and the profile can
>be enabled by setting a property in the component POM, that might be
>worthwhil.
>
>There are some reports that we want to appear in all components; those
>should remain in the parent POM.
>
>> Phil
>>>
>>> Gary
>>>
>>>
>>> On Mon, Mar 25, 2013 at 11:34 AM, Phil Steitz <phil.steitz@gmail.com>
>>>wrote:
>>>
>>>> On 3/25/13 8:12 AM, Emmanuel Bourg wrote:
>>>>> Is it possible to disable cobertura at the component level only?
>>>> The short answer is no.  Its bugged-ness extends to ignoring the
>>>> disabling config.
>>>>
>>>> Phil
>>>>>
>>>>> Emmanuel Bourg
>>>>>
>>>>>
>>>>> Le 25/03/2013 11:01, Luc Maisonobe a écrit :
>>>>>> Hi all,
>>>>>>
>>>>>> We have already discussed about some problems with the cobertura
>>>>>>maven
>>>>>> plugin (see <http://markmail.org/thread/hqckkacin7zby35c> and
>>>>>> <http://markmail.org/thread/7xecuq6shtc4vkzy>).
>>>>>>
>>>>>> As a summary, cobertura seems to not be maintained, there are some
>>>>>>bugs
>>>>>> that trigger errors with [math] (see for example
>>>>>> <
>>>> 
>>>>http://sourceforge.net/tracker/?func=detail&aid=3089579&group_id=130558
>>>>&atid=720015
>>>>> ),
>>>>>> it takes ages on some tests: on my machine, which is not really
>>>>>>fast, it
>>>>>> takes about 9 hours to run [math]!
>>>>>>
>>>>>> As suggested in the threads above, I have tried to remove
>>>>>> instrumentation for the too long BOBYQA tests using this:
>>>>>>
>>>>>>       <plugin>
>>>>>>         <groupId>org.codehaus.mojo</groupId>
>>>>>>         <artifactId>cobertura-maven-plugin</artifactId>
>>>>>>         <version>${commons.cobertura.version}</version>
>>>>>>         <configuration>
>>>>>>           <instrumentation>
>>>>>>             <ignores>
>>>>>>
>>>>>>
>>>> 
>>>><ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAO
>>>>ptimizer</ignore>
>>>>>>
>>>> 
>>>><ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAO
>>>>ptimizerTest</ignore>
>>>>>>
>>>> 
>>>><ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</i
>>>>gnore>
>>>>>>
>>>> 
>>>><ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTes
>>>>t</ignore>
>>>>>>             </ignores>
>>>>>>             <excludes>
>>>>>>
>>>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>>>>>>
>>>>>> 
>>>>>><exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclu
>>>>>>de>
>>>>>>               </excludes>
>>>>>>           </instrumentation>
>>>>>>         </configuration>
>>>>>>       </plugin>
>>>>>>
>>>>>> It failed, the tests are still take ages to run. I tried to add the
>>>>>> previous setting in either build or report sections, none worked.
>>>>>>
>>>>>> It therefore appear there is nothing we can do at [math] level to
>>>>>> prevent this, despite the offending tests do run properly in many
>>>>>>cases
>>>>>> outside of cobertura (there are random errors with exceeded
>>>>>>iteration
>>>>>> count from time to time).
>>>>>>
>>>>>> As we are heading to publish [math] 3.2, it is a very huge problem
>>>>>>for
>>>>>> us. It already was for 3.1.1, and it will be as long as we don't
>>>>>>remove
>>>>>> cobertura.
>>>>>>
>>>>>> As shown with the sonar instance, Jacoco does a fairly good job at
>>>>>> computing coverage.However, it seems it is not as well integrated
>>>>>>into
>>>>>> maven reports as cobertura. In another project, I had to set up a
>>>>>>custom
>>>>>> entry in the menu to point to the generated pages in the site menu.
>>>>>>
>>>>>> Would it be possible to replace cobertura with jacoco in parent pom,
>>>>>> either with a manual link to the generated page or with a proper
>>>>>> integration with other reports?
>>>>>>
>>>>>> best regards,
>>>>>> Luc
>>>>>>
>>>>>> 
>>>>>>---------------------------------------------------------------------
>>>>>> 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
>>
>
>---------------------------------------------------------------------
>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


Mime
View raw message