2012/12/29 Oliver Heger <oliver.he...@oliver-heger.de>: > Am 29.12.2012 21:21, schrieb Phil Steitz: > >> 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? > > > Could we move the major part of the reports into a profile which is not > enabled per default? Then everybody can build a site locally containing all > these reports by just enabling the profile. The official sites would not > contain reports, but reference Sonar. Sounds good call it reporting. If folks want to run cobertura, findbugs etc they just need to add -Preporting. If you want to publish those reports run maven site with it.
> > Oliver > > >>> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
