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

Reply via email to