We should just move the non-development stuff (stuff that we'll run in a CI environment, though) into a profile.
On Sat, Dec 29, 2012 at 7:28 PM, Olivier Lamy <ol...@apache.org> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
