You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2018/02/13 06:32:19 UTC
"Umbrella" discussion
Mark you'd like us to talk about making TomEE an umbrella or not. I think it's probably best you frame up and lead the discussion as you're the most passionate about it and I won't do it justice.
I'd like to suggest that we give it two weeks. If the conversation dies out, we need to read it as lack of interest and not stop people's work.
-David
Re: "Umbrella" discussion
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ra...@yahoo.com.invalid>:
>
> 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 <da...@gmail.com> 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
>
>
Re: "Umbrella" discussion
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 12 avr. 2018 23:24, "gilbertoca" <gi...@gmail.com> a écrit :
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.
If you do you kill subproject as not ee ones (we tried). We need to work on
the new geronimo identity but importing it in tomee is a known end for me.
Tomee users will not notice any diff (tomee is less than 5% of the apache
projects it uses and way less than geronimo code it includes).
I understand your point of view but this is also what killed geronimo as a
server.
Hope we can avoid to do it again ;)
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
Re: "Umbrella" discussion
Posted by gilbertoca <gi...@gmail.com>.
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
Re: "Umbrella" discussion
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
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 <da...@gmail.com> 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
Re: "Umbrella" discussion
Posted by Roberto Cortez <ra...@yahoo.com.INVALID>.
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 <da...@gmail.com> 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
Re: "Umbrella" discussion
Posted by David Blevins <da...@gmail.com>.
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
Re: "Umbrella" discussion
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Yes, I gonna tackle this with a broader explanation.
Btw, I don't agree with the 2 weeks. If you would apply this rule to other topics then TomEE8 would clearly not happen.
This is a discussion where everyone has a say and should be finished with either a clear outcome or a standard vote if there are different opinions.
I'll copy over the arguments from the mail thread to the private@geronimo.a.o and private@tomee.a.o mailing lists from 2018-08-11.
The discussion span for over 2 months back then. And of course the focus back then was about the 'future of Geronimo'.
Please note that I'll only copy my own words as this was a private conversation and others need to copy their own words to public lists.
--------
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.
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
What I do not want is to only get a half baked solution. Either we solve this fully or not at all.
--------
Note: The outcome of this thread was that the Geronimo Application Server got retired in the meantime and Geronimo focuses on delivering reusable components in the EE space.
I'm happy to evaluate this again and move over all those parts to TomEE.
But only IF we find a way to make TomEE a viable Umbrella project.
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.
* 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.
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.
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.
Given that almost all of the active G people are also TomEE committers I think that point 2 is a rather low barrier.
So and now give me some feedback pretty please ;)
LieGrue,
strub
PS: those who have access to the Geroniom lists please read up on the old discussions to gather the full picture.
> Am 13.02.2018 um 07:32 schrieb David Blevins <da...@gmail.com>:
>
> Mark you'd like us to talk about making TomEE an umbrella or not. I think it's probably best you frame up and lead the discussion as you're the most passionate about it and I won't do it justice.
>
> I'd like to suggest that we give it two weeks. If the conversation dies out, we need to read it as lack of interest and not stop people's work.
>
>
> -David
>