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
