XBean is way more than config (it could be split in 3 or 4 projects if you just split it "logically"/by concerns) but the config overlap with config spec sounds too important to compete and since we'll not promote XBean features until it is in the spec I agree it wouldn't be sane.
So sounds we are all good. Side note: we can still rename it to something fun like mapee with a map logo? Joke apart we don't need to keep geronimo in the "main" name if somebody has a nice idea. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-08-30 20:50 GMT+02:00 John D. Ament <[email protected]>: > > > On Tue, Aug 22, 2017 at 8:53 AM Romain Manni-Bucau <[email protected]> > wrote: > >> 2017-08-22 14:05 GMT+02:00 John D. Ament <[email protected]>: >> >>> All, >>> >>> So what do we have to do to get this moving forward? >>> >>> I think a few of us prefer to keep the Geronimo name. Even if it is >>> some of our histories, legacies have you, it may be the future or perhaps a >>> revitalization effort to restore the name. >>> >>> The name Geronimo is actually pretty import from the Apache Indians, so >>> keeping that name also keeps that sort of name trend alive. Which is >>> pretty cool IMHO. >>> >>> I think there's been a bunch of ideas thrown out: >>> >>> - Do nothing. Keep the name as is, formally retire the app server piece >>> (I guess this is just us reasserting the page and starting over?) >>> - Take a new name. I'm not sure if this means creating a new PMC or >>> just finding a new name for the existing PMC, don't really care either way. >>> >>> - Migrate Config to another PMC. >>> - Start a new PMC/project just for config. >>> >>> Do we simply just need to keep those discussions going? >>> >> >> Clearly not (in particular when already solved multiple times ;)). If >> config is ready we can just let it be released. >> > > So then are we in agreement, leave it as Geronimo Config and move forward > with it? MP Config 1.1 is about to be released, so maybe we cut a release > right after that? > > I spoke with David offline. While he raised some concerns about using > XBean and that being where most of the common functionality lived, there's > some legacy issues with in XBean. its a sub-project by itself. Its not an > umbrella, so putting config within that would mean we have to release all > of XBean but releasing config separately makes sense. I confirmed with Mark > today. > > So... let's continue to call it Geronimo Config for now. We can address > later. > > >> >> >>> >>> John >>> >>> >>> On Wed, Aug 9, 2017 at 4:05 AM Mark Struberg <[email protected]> wrote: >>> >>>> >>>> > Not a fan of last one since ultimately it means we must drop the name >>>> in the project and is not consistent with last months discussions IMHO. >>>> >>>> >>>> Well it is imo very well consistent. I also already thought about >>>> simply renaming the G project to something different. I try to explain my >>>> original arguments again: >>>> >>>> All I wanted to prevent is to have half baked solutions and leaving >>>> dead corpse lying on the ground. Either we burry it properly or we keep G >>>> alive. >>>> >>>> There are a few things I want to ensure: >>>> >>>> 1.) A (very) few artifacts are really hard to rename. Mostly the G >>>> specs part. If we change that groupId away from o.a.geronimo then a TON of >>>> projects need to change their poms. That just causes confusion. So whatever >>>> we do, we should imo keep the specs at a single central place and keep the >>>> o.a.geronimo groupId >>>> >>>> 2.) There should be a common place for some Enterprise related common >>>> parts, like the TX-Mgr, the specs, xbean-finder, the config, etc. Basically >>>> everything which is usable as a standalone component but too small to form >>>> an own PMC. There should be ONE go-to place for such parts. We currently >>>> have quite a lot smallish PMCs (BVal, BatchEE, etc) with low activity >>>> because we exactly do NOT have such a place. >>>> I already thought about just moving those parts to the Commons PMC. >>>> That might make perfect sense in some regards but they are not interested >>>> in dealing with TCKs and stuff. >>>> >>>> Now here is what might have been misunderstood: >>>> >>>> 3.) You cannot use the org.apache.geronimo groupId and package name in >>>> DIFFERNT PMCs. So that's an all-or-nothing policy. David Blevins wanted to >>>> move parts of G to TomEE. That's picking the resins. Either we move all the >>>> active and still in use parts (and moving the rest to the attic), or >>>> nothing! And we also cannot move some parts to X and others to Y if they >>>> both use the o.a.geronimo groupId or package names. >>>> >>>> >>>> Yes, the "Geronimo" is often still connected with the G server. And the >>>> G server in the meantime (10 years after it's peak) has not the best >>>> reputation. Calling something Geronimo-bla _might_ make people think of the >>>> Server and might make them think that the G server is still alive or makes >>>> a comeback. That's not the case, but it might be the perception we create >>>> if we name something Geronimo-bla. >>>> >>>> Otoh, moving all that stuff to TomEE is similar. TomEE as a brand is >>>> connected with the end user product, the TomEE server. That's why I was >>>> opposed to that proposal. (But note that I only have exactly ONE -1, as >>>> anybody else) >>>> >>>> I could think about moving all the active G parts to TomEE, >> IF << >>>> * really ALL the active parts are handed over, also the stuff TomEE >>>> doesn't need >>>> * there is a separate brand associated with the reusable components, >>>> and TomEE is just the responsible PMC. It must really be clear that those >>>> reusable components are usable even independent of the TomEE server. >>>> * The reusable parts have separate SCM repositories and a separate >>>> lifecycle! >>>> >>>> In that case we could move the G server and the inactive parts to the >>>> attic. I am fine with that. What I don't want is to have some projects pick >>>> the resins and leave a half dead bloody corpse on the ground. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> > Am 09.08.2017 um 07:08 schrieb Romain Manni-Bucau < >>>> [email protected]>: >>>> > >>>> > I wouldnt go with xbean. Why not naming it if you dont want of G? >>>> > >>>> > Concretely there are 2 options: >>>> > >>>> > - keep G and promote the project with its new goal >>>> > - drop it and name it with something new >>>> > >>>> > Not a fan of last one since ultimately it means we must drop the name >>>> in the project and is not consistent with last months discussions IMHO. >>>> > >>>> > Wdyt? >>>> > >>>> > Le 9 août 2017 02:33, "John D. Ament" <[email protected]> a >>>> écrit : >>>> > Not to stir that pot, but does it make sense to just rename Geronimo >>>> itself to XBean? >>>> > >>>> > I'm assuming then for config you're talking about changing the >>>> coordinates to org.apache.xbean:xbean-config(-impl) ? >>>> > >>>> > John >>>> > >>>> > On Tue, Aug 8, 2017 at 7:15 PM Mark Struberg <[email protected]> >>>> wrote: >>>> > Perfectly fine for me. I'd still give it a different release >>>> lifecycle from the rest of xbean. >>>> > Actually it makes not much sense for the rest of xbean to share the >>>> same version. >>>> > Most of the components do not have any common ground with each other. >>>> > >>>> > LieGrue, >>>> > strub >>>> > >>>> > >>>> > > Am 09.08.2017 um 01:11 schrieb David Blevins < >>>> [email protected]>: >>>> > > >>>> > > Can we rename Geronimo Config? I think the name is strongly stuck >>>> with the app server. From experience in EJB land, try to repurpose names >>>> is usually an uphill battle. >>>> > > >>>> > > If we wanted to go with the grain, we could call it XBean Config. >>>> Open to other names as well. >>>> > > >>>> > > If we did call it XBean Config, I’m not sure there’s a need to have >>>> the same version as the other xbean components. We could, but I think 1.0 >>>> would still be fine. >>>> > > >>>> > > >>>> > > -- >>>> > > David Blevins >>>> > > http://twitter.com/dblevins >>>> > > http://www.tomitribe.com >>>> > > >>>> > >>>> >>>>
