On 25 March 2013 17:48, Phil Steitz <phil.ste...@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.ste...@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-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
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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

Reply via email to