As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end.
- Brett On 19/11/2012, at 9:52 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > cobertura, another usual suspect > > I really don't understand this aspect, and for the moment, I gave up... > > Le dimanche 18 novembre 2012 17:50:02 Benson Margulies a écrit : >> On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: >>> Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit : >>>> Folks, >>>> >>>> I myself feel like a bit of a looping site build myself on this >>>> subject, and I apologize. >>>> >>>> The build of Apache Accumulo is showing the 'classic' symptoms of >>>> running more or less forever with 'site:site', due, apparently, to >>>> some forked execution that causes it to do the same things over and >>>> over. >>>> >>>> Is this really the intended behavior? >>> >>> of course not >>> >>>> I'd like to help cure it, but I am still very much feeling an idiot >>>> about the whole business. >>> >>> this is something really hard to understand then to fix: I'm fighting >>> against such case for a long time now. There was some time I didn't see >>> such a problem. >>> From what I understand, the m-site-p doesn't fork executions but some >>> plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171? >>> Try to remove some javadoc reports, it can help... >> >> In my past life, javadoc loomed large here. In the accumulo build, >> what looks most suspicious is cobertura, which is a big forker of >> executions. >> >> However, given that there are reporting plugins that *do* fork >> executions, what can we do here? Somehow, don't we want to limit the >> execution plans in the forked executions to avoid all this redundancy? >> >>> (sorry, no better idea...) >>> >>> Regards, >>> >>> Hervé >>> >>>> --benson >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
