Guys, just a user here. >From my experience, no one knows the Geronimo project[1] (for me it appears a retired/dead one). Everyone I talk with thinks everything is in TomEE (I thought like this before). Now, after read about the project in the mail-list (several discussion by the way) I understand why the Geronimo project still exists. But it doesn't change the general understanding, TomEE is the official Java EE implementation on Apache Fundation. I think the Geronimo site should be deactivated and the TomEE site, even though is not official umbrella, should be changed to incorporate all projects/sub-projects - like the spring portal[2]. It would show that the Geronimo sub-projects are stronger and are empowering the TomEE engine.
Regards, Gilberto [1] http://geronimo.apache.org/ [2] https://spring.io/projects agumbrecht wrote > I agree with Roberto, that we can create a distinct area under the TomEE > PMC. Now we have a firm name 'Jakarta EE', I think we should grab that > by the horns in some way and run with it! > > I feel that 'anything' EE should not land in 'commons', but should be > actively promoted as an EE component or library, even jakarta-[lib]. > > As I mentioned in the TomEE MP thread already - We should act quickly. > Yes, that may mean we cause ripples or waves in an unforeseen way, but > we also need to keep the 'Apache' noise loud. Especially because Eclipse > is on the leader board here. Anyway, nothing we do is cast in concrete. > > "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" - It 'used' to be this way in TomEE, and it was fun. Between > releases, what goes on in the repo is a playground - Kids should have > fun in the playground until the bell rings. > > In fact, I'm feeling like getting in the playground again with MP and I > think I will just get on with it, get some thick skin, and have fun. I > will of course try and get more fun kids in the playground too, and if > that gets me detention so be it :-P. > > Andy. > > On 27/02/18 15:33, Roberto Cortez wrote: >> >> 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 < > david.blevins@ > > 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 >> > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com > https://www.tomitribe.io > > > Ubique -- Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
