On 12/29/12 10:02 AM, Gary Gregory wrote: > Using Sonar is an orthogonal issue to using reports in the POM. Sure, add > commons components to Sonar, just do not mess up development for all the > other components because one class in [math] is not performing acceptably > for the Cobertura report.
The problem is that the plugin is bugged and effectively impossible to turn off. I think the sonar idea is a great one and consistent with what we have talked about on and off for years - separating the CI-type development reports from the component sites. As we are about to go over the "site deployment cliff ;" now is a great time to think about losing some weight :) I guess an alternative for [math] is to drop commons-parent entirely, just grabbing the stuff we need. Any better suggestions for [math]? Phil > > Gary > > > On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> On 12/29/12 9:46 AM, Oliver Heger wrote: >>> Am 29.12.2012 09:43, schrieb Luc Maisonobe: >>>> Hi Phil, >>>> >>>> Le 28/12/2012 21:10, Phil Steitz a écrit : >>>>> On 12/28/12 11:44 AM, Gary Gregory wrote: >>>>>> It seems a shame to turn off this feature for ALL projects >>>>>> because one >>>>>> project can't figure out a workaround. >>>>> Can *any* project find a workaround? Is there *any way* to turn >>>>> this thing off? >>>> What about every project being declared in the aggregator project >>>> Olivier set up in our instance of Sonar >>>> <https://analysis.apache.org/components/index/121254>? >>>> >>> +1 >>> >>> We could then even disable more reports in the components' poms >>> (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar >>> instance. >>> >>> This would provide comprehensive up-to-date statistics for all >>> components. It would also be a step forward in making the >>> components more uniform. >> +1 - and as yet another bonus, it would reduce wasted infra >> resources duplicating all of the images, etc on all of the >> individual sites and the need to store all of that stuff in svn. >> >> Phil >>> Oliver >>> >>>> Luc >>>> >>>>> Phil >>>>>> Gary >>>>>> >>>>>> On Dec 28, 2012, at 12:21, Phil Steitz <phil.ste...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Any objections to this? In [math] at least we can't seem to >>>>>>> turn it >>>>>>> off and it is causing the site build to take forever. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> 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 >>>> >>> >>> --------------------------------------------------------------------- >>> 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
