On 12/29/12 10:44 AM, Mark Struberg wrote: >> Any better suggestions for [math]? > Yes, as I see it there are two options. > > a.) move some parts into a profile
How exactly would this work? Can we get rid of stuff that way, really? We can get it to ignore stuff the parent specifies? Or are you talking about yet another profile in the parent? > b.) create 2 parent pom. One with the infrastructure stuff and one with all > the tons of additional goodies only needed for the other projects. That seems pretty ugly. I wonder how bad it would be, actually, to just get rid of the parent and define the stuff we actually use / need in [math] itself. I think I have on balance spent more time figuring out what was going on in the parent than I would have spent just maintaining properties actually used by the components that I work on. Maybe just strip it down to some common properties and things like the mailing lists. At the very least, we should drop the reporting section and the one you mention below. > > > LieGrue, > strub > > > PS: I find it pretty weird that the commons-parent has a profile to build all > the other stuff. This can be done much cleaner in having an own > build-aggregator pom which just contains the <modules>. Agreed. I wonder if anyone ever uses this. I would be +1 to drop. Phil > > > ----- Original Message ----- >> From: Phil Steitz <phil.ste...@gmail.com> >> To: Commons Developers List <dev@commons.apache.org> >> Cc: >> Sent: Saturday, December 29, 2012 7:29 PM >> Subject: Re: [commons-parent] drop cobertura >> >> 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 >> > --------------------------------------------------------------------- > 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
