On Sat, Dec 29, 2012 at 8:21 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > 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.
I've used it in the past - useful for testing all components with changes to commons parent or the commons plugin which generates some of the site pages. Its in a profile, so does no harm. Niall > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
