You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <lu...@spaceroots.org> on 2013/03/25 11:01:42 UTC
[all] replacing cobertura with jacoco in parent pom
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.BOBYQAOptimizer</ignore>
<ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
<ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
<ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
</ignores>
<excludes>
<exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
<exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
</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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by "Honton, Charles" <Ch...@intuit.com>.
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" <se...@gmail.com> wrote:
>On 25 March 2013 17:48, Phil Steitz <ph...@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 <ph...@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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by sebb <se...@gmail.com>.
On 25 March 2013 17:48, Phil Steitz <ph...@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 <ph...@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.BOBYQAOptimizer</ignore>
>>>>>
>>> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>>>>>
>>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>>>>>
>>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
>>>>> </ignores>
>>>>> <excludes>
>>>>>
>>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>>>>>
>>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
>>>>> </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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by Phil Steitz <ph...@gmail.com>.
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.
Phil
>
> Gary
>
>
> On Mon, Mar 25, 2013 at 11:34 AM, Phil Steitz <ph...@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.BOBYQAOptimizer</ignore>
>>>>
>> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>>>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>>>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
>>>> </ignores>
>>>> <excludes>
>>>>
>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>>>>
>>>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
>>>> </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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by Gary Gregory <ga...@gmail.com>.
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.
Gary
On Mon, Mar 25, 2013 at 11:34 AM, Phil Steitz <ph...@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.BOBYQAOptimizer</ignore>
> >>
> >>
> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
> >>
> >>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
> >>
> >>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
> >> </ignores>
> >> <excludes>
> >>
> >> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
> >>
> >> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
> >> </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
>
>
--
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: [all] replacing cobertura with jacoco in parent pom
Posted by Phil Steitz <ph...@gmail.com>.
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.BOBYQAOptimizer</ignore>
>>
>> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
>> </ignores>
>> <excludes>
>>
>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>>
>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
>> </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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by Emmanuel Bourg <eb...@apache.org>.
Is it possible to disable cobertura at the component level only?
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.BOBYQAOptimizer</ignore>
>
> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
> </ignores>
> <excludes>
>
> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>
> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
> </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
>
Re: [all] replacing cobertura with jacoco in parent pom
Posted by Phil Steitz <ph...@gmail.com>.
On 3/25/13 3:21 AM, Adrian Crum wrote:
> Is there any way a project can select its own code coverage tool?
> I don't like the top-down, all-or-nothing approach to Commons
> build files.
Big +1 to this. Lets just please drop this from the parent pom.
Phil
>
> -Adrian
>
> On 3/25/2013 10:01 AM, Luc Maisonobe wrote:
>> 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.BOBYQAOptimizer</ignore>
>>
>>
>> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>>
>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>>
>>
>> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
>>
>> </ignores>
>> <excludes>
>>
>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>>
>> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
>>
>> </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
Re: [all] replacing cobertura with jacoco in parent pom
Posted by Adrian Crum <ad...@sandglass-software.com>.
Is there any way a project can select its own code coverage tool? I
don't like the top-down, all-or-nothing approach to Commons build files.
-Adrian
On 3/25/2013 10:01 AM, Luc Maisonobe wrote:
> 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.BOBYQAOptimizer</ignore>
>
> <ignore>org.apache.commons.math3.optim.nonlinear.scalar.noderiv.BOBYQAOptimizerTest</ignore>
>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizer</ignore>
>
> <ignore>org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest</ignore>
> </ignores>
> <excludes>
>
> <exclude>org/apache/commons/math3/**/BOBYQAOptimizer.class</exclude>
>
> <exclude>org/apache/commons/math3/**/BOBYQAOptimizerTest.class</exclude>
> </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