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. > > 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 >> > > >> > >> >>
