Agree, there is no reason the relationship changes today and TomEE can continue to benefit from its server image and consume all the goodness coming from the brand new geronimo status/state without impacting/disturbing its own community.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-02-27 15:33 GMT+01:00 Roberto Cortez <[email protected]>: > > Hi, > I'll +1 on: > 5.) Move the usable components to a disctinct area under the TomEE PMC, > but with a separate brand name. It should _not_ be TomEE components, but > something catchy > > Cheers,Roberto On Sunday, February 25, 2018, 11:50:43 PM GMT, David > Blevins <[email protected]> wrote: > > Huge email, so if I don't respond to a point you were particularly > interested in, do let me know. Adding some thoughts. > > > Again my argument: > > > > > > *) There should be a go-to place for such reusable enterprise parts at > Apache. Like javamail, the tx-mgr, the specs, config, xbean, etc. > > > > *) We should keep the o.a.geronimo.specs groupId (would be tons of work > for downstream projects to change it) and we cannot have multiple PMCs > using this groupId and package name. > > > > *) Those reusable parts should have an own marketing name. We could > reuse XBean or find a better one. > > Why? Geronimo is associated with a big and dead EE server, TomEE is > associated with an alive EE server. Better, but not much. > > It should be clear that those reusable components are actually > independent of each of the 3 projects. > > > > *) The reusablel parts each also have a separate livecycle. > > > > *) If we really shutdown Geronimo then all the active components should > be moved to another project, the rest goes to the attic. > > > > *) I totally don't care which PMC does the organisatorial thing as long > as it is active. That would be a plus for the TomEE PMC as it is reasonably > more active. We did not even get enough +1 for the last votes over here. > That's not making me happy. > > I agree with the community perspective that having us all split into a > couple weak PMCs is not ideal. I think we'd be stronger together. > > More reusable components released separately is a good way to keep build > times down. There's a cost to that, so pragmatism is definitely required. > > Some things are a couple lines of code. Some things are a library in a > git repo. Some things are their own repo, but not big enough for a PMC. > Some things need to be their own standalone project. > > The above said, they are all very subjective so what's really important to > me is that freedom still exist. > > - I'm not a fan of seeing "you can't do x because y project owns it" > > - I'm not a fan of abstracting code before I've written it as flat as > possible first > > - We would need an exceptionally positive environment that favors > creativity and tolerates bending the rules > > As an example of reuse, I wrote xbean-finder in OpenEJB first as a few > classes right in openejb-core module. I was just trying to get my head > around annotation processing and all the new requirements for EJB 3.0. > Once things were working and it was clear I was on the right path, I > cleaned it up and split it out as a module in xbean. I wrote xbean-telnet > like that as well as xbean-classpath. James Strachan and Hiram Chirino > wrote xbean-spring in ActiveMQ first then moved it over. > > Dain Sundstrom wrote xbean-reflect and xbean-naming there first, from the > get-go. That's the way he worked. His brain works differently than mine > or James'. We all achieved amazing reusable results, just each in our > different ways. > > We gave each other a lot of free space, which is why we stayed motivated > to keep adding code there instead of keeping it in our projects. I didn't > get a chance to work with James and Hiram much otherwise, for example. > > The flexible and "creativity over rules" spirit kept it fun. When hard > lines are taken, it becomes not fun very quickly. > > I'd want to see tolerance that it is ok to not aim for reuse on the first > line of code. I wouldn't want to see long debates that basically mean > people can't code around how their brain works, experiment to fill gaps in > knowledge or general preference to move fast and go for reuse after. > > Reuse was also only ever voluntary. At no point did any of us (OpenEJB, > Geronimo, ActiveMQ, ServiceMix) show up on each others lists and demand > reuse or call people out. We definitely did say, "hey that code looks > awesome, what do you think about adding it to xbean?" Sometimes they did, > sometimes not. > > Some people in Apache didn't want the dependency on xbean so they forked > the code. I can't recall exactly which project, maybe Struts, forked > xbean-finder because they didn't feel there was enough code there to > justify a dependency. I was ok with that and helped them understand the > code so they could take what they needed. > > > So far we have a few possible solutions: > > > > 1.) Keep Geronimo but burry the G server and change all the site, etc to > make it sure that the public understands that G is now essentially > something else. Not sure if this works > > 2.) Same as 1 plus rename the Geronimo project to some other name (but > still keep a.o.geronimo.specs). > > 3.) Create a new PMC with the usable components > > 4.) Move the usable parts to Commons > > 5.) Move the usable components to a disctinct area under the TomEE PMC, > but with a separate brand name. It should _not_ be TomEE components, but > something catchy > > My preferences in order: 5, 2 > > Historical note: Xbean originally started as a separate project at > Codehaus. It eventually moved in as a subproject of Geronimo. > > > What I do NOT want to happen: > > * have components which are not reusable in other projects but tightly > coupled to the TomEE Application Server > > We have tons of projects who make use of the Geronimo components. Think > about the geronimo-transactionmanager. It's used in OpenJPA, CXF, ActiveMQ, > and even many external projects. The same will happens (or already > happened) with the Geronimo based Miroprofile spec implementations. > > To be clear, I am ok with having things in TomEE that are tightly coupled > with TomEE. It just depends on what it is. Regardless of which places at > Apache are available for making reusable things, I'd still want to continue > allowing TomEE to strategically have tightly integrated code and the > project to make the decision for itself what is worth the cost of reuse. > > A major focus of Geronimo was it's module system and constant focus on > components that could be plugged in. The resulting code was severely > complex because all layers were attempting to always abstract from one > another. > > A major motivation for creating TomEE vs just continuing to work on > Geronimo was seeing what it could look like to go the opposite way. I > often describe TomEE is a laptop approach whereas most servers take a > desktop approach. I think we've achieved the small footprint we have > because of it and we could get smaller if we did more of it. > > This isn't an objection, just an FYI that tight coupling is in the spirit > of TomEE. > > > * have users getting confused about the name 'TomEE'. Does it refer to > the project? Does it refer to the App Server? Does it refer to some > components which might be used on other app servers even? > > We had this problem in MyFaces. That was the number one reason why > things like myfaces-ext-cdi (CODI) and my faces-ext-validation only had > limited reach. > > If I'd got just one dollar for every time I got the feedback that 'CODI > looks great, but sadly it only runs on MyFaces, but we have Mojarra'. > > That is the number one reason why we extracted CODI out of MyFaces and > created DeltaSpike. > > > > The same happened with openwebbeans-test-control. The API also worked > perfectly fine with other containers. But nobody adopted it until we moved > the code 1:1 to DeltaSpike as deltaspike-cdictrl. > > Agree that people have a hard time seeing past the branding. It was > difficult to get people to think of this project as broad as it truly was > while it was named OpenEJB. It didn't matter what work went into evolving > the EJB spec, reminding people EJB is not as narrow as they describe it so > we support JAX-WS, JMS and more. When we renamed it to TomEE, it was 5x > easier to get people to see what was there. > > > Oh and Geronimo had this problem as well. Of course, now that the G app > server is officially dead this is a bit easier to explain. > > This is where we disagree. I think the Geronimo brand is cemented and a > rename is required should there be any hope. > > > That leads me to the following 2 points which we must solve: > > * Make it sure that those components are totally independent from the > 'TomEE Appliation Server' part > > * Make that fact clear to users. So we need a different brand name for > this part. > > That could even be 'Geronimo Components' hosted at the TomEE project. > > I'd also keep the org.apache.geronimo package name and groupId. They are > widely used and esatablished. > > > > Of course this requires 2 things: > > 1.) the TomEE community wants this to happen > > 2.) the Geronimo community wants this to let go. > > I'm personally ok with both 1 and 2. I'm also ok if they don't happen. > My preference would be for merging. > > A note for clarity. OpenEJB/TomEE has always had a reusable component > relationship with Geronimo and I don't see a problem with it continuing. > From 2005-2012 quite a lot of work was done in Xbean by people in the > OpenEJB, ActiveMQ, ServiceMix and Geronimo communities. > > Should no decision to merge Geronimo into TomEE be made, I'd expect the > relationship between TomEE/Geronimo to continue as it always has. > > > -David > >
