Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

Hi Alan!

> The commit activity you speak of is really just small number of minor patches 
> and a merge of years of work by IBM. 

No, this was all done in one big fat commit. 

There really have been 60 other committs during that time!
So it's not just a one-time effect due to Yoko.

I have to admit that I did read your post about "runtime-configurations for 
heterogeneous global environments" and didn't yet fully grok it. 
Is this like a dependency graph, but not only at build time but also during 
runtime?

Or do you really talk about 'configuration'? Then this is exactly what I 
proposed to add to geronimo as a component one year ago isn't?
Just think about adding a ConfigSource which goes to Zookeeper, Consul or just 
a GIT server.

https://github.com/struberg/javaConfig/tree/originalProposalJune2016

Is this something in the direction you have been talking about?

> deck chairs on the Titanic
I bet one could make a huge amount of money with it ;)


LieGrue,
strub


> Am 01.04.2017 um 08:25 schrieb Alan Cabrera :
> 
> The commit activity you speak of is really just small number of minor patches 
> and a merge of years of work by IBM.  I’m just adding a bit of clarity there. 
>  On it’s own, it indicates to me that the “home for Java API specs” is not a 
> fruitful path.  As it stands, there’s not a lot of activity and I still 
> haven’t heard a clear case that things will ever improve on that front.
> 
> With that said, I think the config front will be very fruitful.  I’ve already 
> outlined my ideas and I think that Geronimo would be a good seed from which 
> to start with.
> I’ll stick around to work on configuration on a macro level.  Hopefully it 
> will dovetail with your work.
> 
> We could still keep the specs around.  I see no harm in that.
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
>> 
>> Of course we do not have a huge community. But a very long lasting one. And 
>> there is not really standstill. There have been 64 committs in the last 3 
>> monts. This is actually not too bad!
>> 
>> So how to move on?
>> 
>> Who wants to remain active in the PMC? Who wants to leave?
>> 
>> We already pinned down the parts where there certainly IS community. 
>> In addition to that I would like to bring in Geronimo-Config  as an 
>> implementation of the Microprofile-Config specification.
>> Discussions have been going on last year all work has been done by me on my 
>> github account. But would love to bring it over here.
>> 
>> I'll dig the old projects charter and try to kick off a reboot together with 
>> Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have 
>> a helping hand from time to time. Note that everyone is welcome, even if he 
>> currently has no time to commit but only wants to provide guide and feedback.
>> 
>> The first step I recommend is be to merge various mailing lists together.
>> Then we need to verify the charter and probably tweak it for the new goal.
>> We also need to communicate that we do not further maintain the Geronimo 
>> Server parts.
>> 
>> Any objection?
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>>> 
>>> "need" and "in use" does not necessarily translate into community. The need 
>>> for the geronimo components that have been discussed is not new. As far as 
>>> I can tell, so far, that has not translated into a community. 
>>> 
>>> If we want to continue the project, demonstrate the community that is 
>>> needed for the project to continue. As I stated previously, a good starting 
>>> point: create a new charter for the project, identify active PMC 
>>> members/committers, and obtain board approval. 
>>> 
>>> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:
>>> Hi Alan!
>>> 
>>> There are quite a few things which fit into this scenario imo.
>>> 
>>> I think we really miss some 'toolbox project' for EE components at the ASF.
>>> There was a tendency to make all those projects own TLPs for some time. But 
>>> that approach simply doesn't scale, and we end up with the same people in 
>>> most of those projects anyway.
>>> So moving the ones with lower activity into a common TLP would solve this 
>>> problem. Geronimo could probably become this project.
>>> 
>>> There are a lot old EE folks around which have tremendous knowledge. And 
>>> there are certain technologies which are really cool, but have the 
>>> classical EE-lifecycle up-down in terms of activity.
>>> That + the already existing components could be a great chance.
>>> 
>>> As you already said yourself: the terms of the big fat EE servers is over. 
>>> But nevertheless the technology and requirement behind most of the single 
>>> parts is still valid and often unbeaten.
>>> But nowadays it's more about making it easy to plug & play those technology 
>>> libs together more freely as they are needed. Thus moving the focus on 
>>> maintaining the components and not the server could be really appreci

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

The commit activity you speak of is really just small number of minor patches 
and a merge of years of work by IBM.  I’m just adding a bit of clarity there.  
On it’s own, it indicates to me that the “home for Java API specs” is not a 
fruitful path.  As it stands, there’s not a lot of activity and I still haven’t 
heard a clear case that things will ever improve on that front.

With that said, I think the config front will be very fruitful.  I’ve already 
outlined my ideas and I think that Geronimo would be a good seed from which to 
start with.
I’ll stick around to work on configuration on a macro level.  Hopefully it will 
dovetail with your work.

We could still keep the specs around.  I see no harm in that.


Regards,
Alan



> On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
> 
> Of course we do not have a huge community. But a very long lasting one. And 
> there is not really standstill. There have been 64 committs in the last 3 
> monts. This is actually not too bad!
> 
> So how to move on?
> 
> Who wants to remain active in the PMC? Who wants to leave?
> 
> We already pinned down the parts where there certainly IS community. 
> In addition to that I would like to bring in Geronimo-Config  as an 
> implementation of the Microprofile-Config specification.
> Discussions have been going on last year all work has been done by me on my 
> github account. But would love to bring it over here.
> 
> I'll dig the old projects charter and try to kick off a reboot together with 
> Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have a 
> helping hand from time to time. Note that everyone is welcome, even if he 
> currently has no time to commit but only wants to provide guide and feedback.
> 
> The first step I recommend is be to merge various mailing lists together.
> Then we need to verify the charter and probably tweak it for the new goal.
> We also need to communicate that we do not further maintain the Geronimo 
> Server parts.
> 
> Any objection?
> 
> LieGrue,
> strub
> 
> 
>> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>> 
>> "need" and "in use" does not necessarily translate into community. The need 
>> for the geronimo components that have been discussed is not new. As far as I 
>> can tell, so far, that has not translated into a community. 
>> 
>> If we want to continue the project, demonstrate the community that is needed 
>> for the project to continue. As I stated previously, a good starting point: 
>> create a new charter for the project, identify active PMC 
>> members/committers, and obtain board approval. 
>> 
>> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:
>> Hi Alan!
>> 
>> There are quite a few things which fit into this scenario imo.
>> 
>> I think we really miss some 'toolbox project' for EE components at the ASF.
>> There was a tendency to make all those projects own TLPs for some time. But 
>> that approach simply doesn't scale, and we end up with the same people in 
>> most of those projects anyway.
>> So moving the ones with lower activity into a common TLP would solve this 
>> problem. Geronimo could probably become this project.
>> 
>> There are a lot old EE folks around which have tremendous knowledge. And 
>> there are certain technologies which are really cool, but have the classical 
>> EE-lifecycle up-down in terms of activity.
>> That + the already existing components could be a great chance.
>> 
>> As you already said yourself: the terms of the big fat EE servers is over. 
>> But nevertheless the technology and requirement behind most of the single 
>> parts is still valid and often unbeaten.
>> But nowadays it's more about making it easy to plug & play those technology 
>> libs together more freely as they are needed. Thus moving the focus on 
>> maintaining the components and not the server could be really appreciated by 
>> the community.
>> 
>> You said there will be community if there is a need. I fully agree, and even 
>> more I see a need for those parts.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
>>> 
>>> After a good night’s sleep, I re-read this thread and I’ll respond without 
>>> trying to guide you in where and how you decide to go with your efforts; 
>>> thanks in advance for letting me reboot my reply.  :)
>>> 
>>> Any pivot that this community decides upon, will have to be justified to 
>>> the ASF board.  We will need to explain what will be different and justify 
>>> how it will generate sustainable community activity.  With regards to that, 
>>> I have two general concerns:
>>>  • Will this this specific endeavor generate any new sustainable 
>>> community activity?
>>>  • Will any new activity of this specific endeavor represent activity 
>>> that is unique to Geronimo or are we doing the chores of other projects to 
>>> provide the appearance of activity?
>>> The current level activity, is due to spec maintenance for downstream 
>>> dependencies and we must admit that it is

Re: Discuss: Move Geronimo to Attic

[Jason Warner]

I have not been active for a long time, so I will also be leaving.

On Mar 26, 2017 3:08 PM, "Jason Dillon"  wrote:

I will be leaving as well.

—jason


On March 26, 2017 at 12:01:05 PM, Kevan Miller (kevan.mil...@gmail.com)
wrote:

I'll be leaving.

On Fri, Mar 24, 2017 at 4:21 PM, Romain Manni-Bucau 
wrote:

> +1
>
> Le 25 mars 2017 00:17, "David Jencks"  a écrit :
>
>> I like this approach.  Thank you for making a concrete suggestion and
>> taking the lead. I intend to stay on the PMC and at least occasionally help
>> out.
>>
>> david jencks
>>
>> > On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
>> >
>> > Of course we do not have a huge community. But a very long lasting one.
>> And there is not really standstill. There have been 64 committs in the last
>> 3 monts. This is actually not too bad!
>> >
>> > So how to move on?
>> >
>> > Who wants to remain active in the PMC? Who wants to leave?
>> >
>> > We already pinned down the parts where there certainly IS community.
>> > In addition to that I would like to bring in Geronimo-Config  as an
>> implementation of the Microprofile-Config specification.
>> > Discussions have been going on last year all work has been done by me
>> on my github account. But would love to bring it over here.
>> >
>> > I'll dig the old projects charter and try to kick off a reboot together
>> with Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to
>> have a helping hand from time to time. Note that everyone is welcome, even
>> if he currently has no time to commit but only wants to provide guide and
>> feedback.
>> >
>> > The first step I recommend is be to merge various mailing lists
>> together.
>> > Then we need to verify the charter and probably tweak it for the new
>> goal.
>> > We also need to communicate that we do not further maintain the
>> Geronimo Server parts.
>> >
>> > Any objection?
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>> >>
>> >> "need" and "in use" does not necessarily translate into community. The
>> need for the geronimo components that have been discussed is not new. As
>> far as I can tell, so far, that has not translated into a community.
>> >>
>> >> If we want to continue the project, demonstrate the community that is
>> needed for the project to continue. As I stated previously, a good starting
>> point: create a new charter for the project, identify active PMC
>> members/committers, and obtain board approval.
>> >>
>> >> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg 
>> wrote:
>> >> Hi Alan!
>> >>
>> >> There are quite a few things which fit into this scenario imo.
>> >>
>> >> I think we really miss some 'toolbox project' for EE components at the
>> ASF.
>> >> There was a tendency to make all those projects own TLPs for some
>> time. But that approach simply doesn't scale, and we end up with the same
>> people in most of those projects anyway.
>> >> So moving the ones with lower activity into a common TLP would solve
>> this problem. Geronimo could probably become this project.
>> >>
>> >> There are a lot old EE folks around which have tremendous knowledge.
>> And there are certain technologies which are really cool, but have the
>> classical EE-lifecycle up-down in terms of activity.
>> >> That + the already existing components could be a great chance.
>> >>
>> >> As you already said yourself: the terms of the big fat EE servers is
>> over. But nevertheless the technology and requirement behind most of the
>> single parts is still valid and often unbeaten.
>> >> But nowadays it's more about making it easy to plug & play those
>> technology libs together more freely as they are needed. Thus moving the
>> focus on maintaining the components and not the server could be really
>> appreciated by the community.
>> >>
>> >> You said there will be community if there is a need. I fully agree,
>> and even more I see a need for those parts.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
>> >>>
>> >>> After a good night’s sleep, I re-read this thread and I’ll respond
>> without trying to guide you in where and how you decide to go with your
>> efforts; thanks in advance for letting me reboot my reply.  :)
>> >>>
>> >>> Any pivot that this community decides upon, will have to be justified
>> to the ASF board.  We will need to explain what will be different and
>> justify how it will generate sustainable community activity.  With regards
>> to that, I have two general concerns:
>> >>>  • Will this this specific endeavor generate any new sustainable
>> community activity?
>> >>>  • Will any new activity of this specific endeavor represent
>> activity that is unique to Geronimo or are we doing the chores of other
>> projects to provide the appearance of activity?
>> >>> The current level activity, is due to spec maintenance for downstream
>> dependencies and we must admit that it is quite low.  Being an upstream
>> “aggregator” does not 

Re: Discuss: Move Geronimo to Attic

[Jason Dillon]

I will be leaving as well.

—jason


On March 26, 2017 at 12:01:05 PM, Kevan Miller (kevan.mil...@gmail.com) wrote:

I'll be leaving.

On Fri, Mar 24, 2017 at 4:21 PM, Romain Manni-Bucau  
wrote:
+1

Le 25 mars 2017 00:17, "David Jencks"  a écrit :
I like this approach.  Thank you for making a concrete suggestion and taking 
the lead. I intend to stay on the PMC and at least occasionally help out.

david jencks

> On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
>
> Of course we do not have a huge community. But a very long lasting one. And 
> there is not really standstill. There have been 64 committs in the last 3 
> monts. This is actually not too bad!
>
> So how to move on?
>
> Who wants to remain active in the PMC? Who wants to leave?
>
> We already pinned down the parts where there certainly IS community.
> In addition to that I would like to bring in Geronimo-Config  as an 
> implementation of the Microprofile-Config specification.
> Discussions have been going on last year all work has been done by me on my 
> github account. But would love to bring it over here.
>
> I'll dig the old projects charter and try to kick off a reboot together with 
> Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have a 
> helping hand from time to time. Note that everyone is welcome, even if he 
> currently has no time to commit but only wants to provide guide and feedback.
>
> The first step I recommend is be to merge various mailing lists together.
> Then we need to verify the charter and probably tweak it for the new goal.
> We also need to communicate that we do not further maintain the Geronimo 
> Server parts.
>
> Any objection?
>
> LieGrue,
> strub
>
>
>> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>>
>> "need" and "in use" does not necessarily translate into community. The need 
>> for the geronimo components that have been discussed is not new. As far as I 
>> can tell, so far, that has not translated into a community.
>>
>> If we want to continue the project, demonstrate the community that is needed 
>> for the project to continue. As I stated previously, a good starting point: 
>> create a new charter for the project, identify active PMC 
>> members/committers, and obtain board approval.
>>
>> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:
>> Hi Alan!
>>
>> There are quite a few things which fit into this scenario imo.
>>
>> I think we really miss some 'toolbox project' for EE components at the ASF.
>> There was a tendency to make all those projects own TLPs for some time. But 
>> that approach simply doesn't scale, and we end up with the same people in 
>> most of those projects anyway.
>> So moving the ones with lower activity into a common TLP would solve this 
>> problem. Geronimo could probably become this project.
>>
>> There are a lot old EE folks around which have tremendous knowledge. And 
>> there are certain technologies which are really cool, but have the classical 
>> EE-lifecycle up-down in terms of activity.
>> That + the already existing components could be a great chance.
>>
>> As you already said yourself: the terms of the big fat EE servers is over. 
>> But nevertheless the technology and requirement behind most of the single 
>> parts is still valid and often unbeaten.
>> But nowadays it's more about making it easy to plug & play those technology 
>> libs together more freely as they are needed. Thus moving the focus on 
>> maintaining the components and not the server could be really appreciated by 
>> the community.
>>
>> You said there will be community if there is a need. I fully agree, and even 
>> more I see a need for those parts.
>>
>> LieGrue,
>> strub
>>
>>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
>>>
>>> After a good night’s sleep, I re-read this thread and I’ll respond without 
>>> trying to guide you in where and how you decide to go with your efforts; 
>>> thanks in advance for letting me reboot my reply.  :)
>>>
>>> Any pivot that this community decides upon, will have to be justified to 
>>> the ASF board.  We will need to explain what will be different and justify 
>>> how it will generate sustainable community activity.  With regards to that, 
>>> I have two general concerns:
>>>      • Will this this specific endeavor generate any new sustainable 
>>>community activity?
>>>      • Will any new activity of this specific endeavor represent activity 
>>>that is unique to Geronimo or are we doing the chores of other projects to 
>>>provide the appearance of activity?
>>> The current level activity, is due to spec maintenance for downstream 
>>> dependencies and we must admit that it is quite low.  Being an upstream 
>>> “aggregator” does not provide appreciable added value at the cost of the 
>>> doubled administration.  The specter of duplicate work will, in reality, 
>>> never arise; this de facto efficiency is due to the awesomeness of the ASL 
>>> 2.0 license.  The case for being an aggregator weakens even more given the 
>>> f

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

I'll be leaving.

On Fri, Mar 24, 2017 at 4:21 PM, Romain Manni-Bucau 
wrote:

> +1
>
> Le 25 mars 2017 00:17, "David Jencks"  a écrit :
>
>> I like this approach.  Thank you for making a concrete suggestion and
>> taking the lead. I intend to stay on the PMC and at least occasionally help
>> out.
>>
>> david jencks
>>
>> > On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
>> >
>> > Of course we do not have a huge community. But a very long lasting one.
>> And there is not really standstill. There have been 64 committs in the last
>> 3 monts. This is actually not too bad!
>> >
>> > So how to move on?
>> >
>> > Who wants to remain active in the PMC? Who wants to leave?
>> >
>> > We already pinned down the parts where there certainly IS community.
>> > In addition to that I would like to bring in Geronimo-Config  as an
>> implementation of the Microprofile-Config specification.
>> > Discussions have been going on last year all work has been done by me
>> on my github account. But would love to bring it over here.
>> >
>> > I'll dig the old projects charter and try to kick off a reboot together
>> with Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to
>> have a helping hand from time to time. Note that everyone is welcome, even
>> if he currently has no time to commit but only wants to provide guide and
>> feedback.
>> >
>> > The first step I recommend is be to merge various mailing lists
>> together.
>> > Then we need to verify the charter and probably tweak it for the new
>> goal.
>> > We also need to communicate that we do not further maintain the
>> Geronimo Server parts.
>> >
>> > Any objection?
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>> >>
>> >> "need" and "in use" does not necessarily translate into community. The
>> need for the geronimo components that have been discussed is not new. As
>> far as I can tell, so far, that has not translated into a community.
>> >>
>> >> If we want to continue the project, demonstrate the community that is
>> needed for the project to continue. As I stated previously, a good starting
>> point: create a new charter for the project, identify active PMC
>> members/committers, and obtain board approval.
>> >>
>> >> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg 
>> wrote:
>> >> Hi Alan!
>> >>
>> >> There are quite a few things which fit into this scenario imo.
>> >>
>> >> I think we really miss some 'toolbox project' for EE components at the
>> ASF.
>> >> There was a tendency to make all those projects own TLPs for some
>> time. But that approach simply doesn't scale, and we end up with the same
>> people in most of those projects anyway.
>> >> So moving the ones with lower activity into a common TLP would solve
>> this problem. Geronimo could probably become this project.
>> >>
>> >> There are a lot old EE folks around which have tremendous knowledge.
>> And there are certain technologies which are really cool, but have the
>> classical EE-lifecycle up-down in terms of activity.
>> >> That + the already existing components could be a great chance.
>> >>
>> >> As you already said yourself: the terms of the big fat EE servers is
>> over. But nevertheless the technology and requirement behind most of the
>> single parts is still valid and often unbeaten.
>> >> But nowadays it's more about making it easy to plug & play those
>> technology libs together more freely as they are needed. Thus moving the
>> focus on maintaining the components and not the server could be really
>> appreciated by the community.
>> >>
>> >> You said there will be community if there is a need. I fully agree,
>> and even more I see a need for those parts.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
>> >>>
>> >>> After a good night’s sleep, I re-read this thread and I’ll respond
>> without trying to guide you in where and how you decide to go with your
>> efforts; thanks in advance for letting me reboot my reply.  :)
>> >>>
>> >>> Any pivot that this community decides upon, will have to be justified
>> to the ASF board.  We will need to explain what will be different and
>> justify how it will generate sustainable community activity.  With regards
>> to that, I have two general concerns:
>> >>>  • Will this this specific endeavor generate any new sustainable
>> community activity?
>> >>>  • Will any new activity of this specific endeavor represent
>> activity that is unique to Geronimo or are we doing the chores of other
>> projects to provide the appearance of activity?
>> >>> The current level activity, is due to spec maintenance for downstream
>> dependencies and we must admit that it is quite low.  Being an upstream
>> “aggregator” does not provide appreciable added value at the cost of the
>> doubled administration.  The specter of duplicate work will, in reality,
>> never arise; this de facto efficiency is due to the awesomeness of the ASL
>> 2.0 license.  The case for

Re: Discuss: Move Geronimo to Attic

[Romain Manni-Bucau]

+1

Le 25 mars 2017 00:17, "David Jencks"  a écrit :

> I like this approach.  Thank you for making a concrete suggestion and
> taking the lead. I intend to stay on the PMC and at least occasionally help
> out.
>
> david jencks
>
> > On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
> >
> > Of course we do not have a huge community. But a very long lasting one.
> And there is not really standstill. There have been 64 committs in the last
> 3 monts. This is actually not too bad!
> >
> > So how to move on?
> >
> > Who wants to remain active in the PMC? Who wants to leave?
> >
> > We already pinned down the parts where there certainly IS community.
> > In addition to that I would like to bring in Geronimo-Config  as an
> implementation of the Microprofile-Config specification.
> > Discussions have been going on last year all work has been done by me on
> my github account. But would love to bring it over here.
> >
> > I'll dig the old projects charter and try to kick off a reboot together
> with Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to
> have a helping hand from time to time. Note that everyone is welcome, even
> if he currently has no time to commit but only wants to provide guide and
> feedback.
> >
> > The first step I recommend is be to merge various mailing lists together.
> > Then we need to verify the charter and probably tweak it for the new
> goal.
> > We also need to communicate that we do not further maintain the Geronimo
> Server parts.
> >
> > Any objection?
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
> >>
> >> "need" and "in use" does not necessarily translate into community. The
> need for the geronimo components that have been discussed is not new. As
> far as I can tell, so far, that has not translated into a community.
> >>
> >> If we want to continue the project, demonstrate the community that is
> needed for the project to continue. As I stated previously, a good starting
> point: create a new charter for the project, identify active PMC
> members/committers, and obtain board approval.
> >>
> >> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg 
> wrote:
> >> Hi Alan!
> >>
> >> There are quite a few things which fit into this scenario imo.
> >>
> >> I think we really miss some 'toolbox project' for EE components at the
> ASF.
> >> There was a tendency to make all those projects own TLPs for some time.
> But that approach simply doesn't scale, and we end up with the same people
> in most of those projects anyway.
> >> So moving the ones with lower activity into a common TLP would solve
> this problem. Geronimo could probably become this project.
> >>
> >> There are a lot old EE folks around which have tremendous knowledge.
> And there are certain technologies which are really cool, but have the
> classical EE-lifecycle up-down in terms of activity.
> >> That + the already existing components could be a great chance.
> >>
> >> As you already said yourself: the terms of the big fat EE servers is
> over. But nevertheless the technology and requirement behind most of the
> single parts is still valid and often unbeaten.
> >> But nowadays it's more about making it easy to plug & play those
> technology libs together more freely as they are needed. Thus moving the
> focus on maintaining the components and not the server could be really
> appreciated by the community.
> >>
> >> You said there will be community if there is a need. I fully agree, and
> even more I see a need for those parts.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
> >>>
> >>> After a good night’s sleep, I re-read this thread and I’ll respond
> without trying to guide you in where and how you decide to go with your
> efforts; thanks in advance for letting me reboot my reply.  :)
> >>>
> >>> Any pivot that this community decides upon, will have to be justified
> to the ASF board.  We will need to explain what will be different and
> justify how it will generate sustainable community activity.  With regards
> to that, I have two general concerns:
> >>>  • Will this this specific endeavor generate any new sustainable
> community activity?
> >>>  • Will any new activity of this specific endeavor represent
> activity that is unique to Geronimo or are we doing the chores of other
> projects to provide the appearance of activity?
> >>> The current level activity, is due to spec maintenance for downstream
> dependencies and we must admit that it is quite low.  Being an upstream
> “aggregator” does not provide appreciable added value at the cost of the
> doubled administration.  The specter of duplicate work will, in reality,
> never arise; this de facto efficiency is due to the awesomeness of the ASL
> 2.0 license.  The case for being an aggregator weakens even more given the
> fact that there just isn't a lot of work involved in maintaining specs.
> >>>
> >>> Things aren’t much better for the shared sub-systems.  If 

Re: Discuss: Move Geronimo to Attic

[David Jencks]

I like this approach.  Thank you for making a concrete suggestion and taking 
the lead. I intend to stay on the PMC and at least occasionally help out.

david jencks

> On Mar 24, 2017, at 8:55 AM, Mark Struberg  wrote:
> 
> Of course we do not have a huge community. But a very long lasting one. And 
> there is not really standstill. There have been 64 committs in the last 3 
> monts. This is actually not too bad!
> 
> So how to move on?
> 
> Who wants to remain active in the PMC? Who wants to leave?
> 
> We already pinned down the parts where there certainly IS community. 
> In addition to that I would like to bring in Geronimo-Config  as an 
> implementation of the Microprofile-Config specification.
> Discussions have been going on last year all work has been done by me on my 
> github account. But would love to bring it over here.
> 
> I'll dig the old projects charter and try to kick off a reboot together with 
> Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have a 
> helping hand from time to time. Note that everyone is welcome, even if he 
> currently has no time to commit but only wants to provide guide and feedback.
> 
> The first step I recommend is be to merge various mailing lists together.
> Then we need to verify the charter and probably tweak it for the new goal.
> We also need to communicate that we do not further maintain the Geronimo 
> Server parts.
> 
> Any objection?
> 
> LieGrue,
> strub
> 
> 
>> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
>> 
>> "need" and "in use" does not necessarily translate into community. The need 
>> for the geronimo components that have been discussed is not new. As far as I 
>> can tell, so far, that has not translated into a community. 
>> 
>> If we want to continue the project, demonstrate the community that is needed 
>> for the project to continue. As I stated previously, a good starting point: 
>> create a new charter for the project, identify active PMC 
>> members/committers, and obtain board approval. 
>> 
>> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:
>> Hi Alan!
>> 
>> There are quite a few things which fit into this scenario imo.
>> 
>> I think we really miss some 'toolbox project' for EE components at the ASF.
>> There was a tendency to make all those projects own TLPs for some time. But 
>> that approach simply doesn't scale, and we end up with the same people in 
>> most of those projects anyway.
>> So moving the ones with lower activity into a common TLP would solve this 
>> problem. Geronimo could probably become this project.
>> 
>> There are a lot old EE folks around which have tremendous knowledge. And 
>> there are certain technologies which are really cool, but have the classical 
>> EE-lifecycle up-down in terms of activity.
>> That + the already existing components could be a great chance.
>> 
>> As you already said yourself: the terms of the big fat EE servers is over. 
>> But nevertheless the technology and requirement behind most of the single 
>> parts is still valid and often unbeaten.
>> But nowadays it's more about making it easy to plug & play those technology 
>> libs together more freely as they are needed. Thus moving the focus on 
>> maintaining the components and not the server could be really appreciated by 
>> the community.
>> 
>> You said there will be community if there is a need. I fully agree, and even 
>> more I see a need for those parts.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
>>> 
>>> After a good night’s sleep, I re-read this thread and I’ll respond without 
>>> trying to guide you in where and how you decide to go with your efforts; 
>>> thanks in advance for letting me reboot my reply.  :)
>>> 
>>> Any pivot that this community decides upon, will have to be justified to 
>>> the ASF board.  We will need to explain what will be different and justify 
>>> how it will generate sustainable community activity.  With regards to that, 
>>> I have two general concerns:
>>>  • Will this this specific endeavor generate any new sustainable 
>>> community activity?
>>>  • Will any new activity of this specific endeavor represent activity 
>>> that is unique to Geronimo or are we doing the chores of other projects to 
>>> provide the appearance of activity?
>>> The current level activity, is due to spec maintenance for downstream 
>>> dependencies and we must admit that it is quite low.  Being an upstream 
>>> “aggregator” does not provide appreciable added value at the cost of the 
>>> doubled administration.  The specter of duplicate work will, in reality, 
>>> never arise; this de facto efficiency is due to the awesomeness of the ASL 
>>> 2.0 license.  The case for being an aggregator weakens even more given the 
>>> fact that there just isn't a lot of work involved in maintaining specs.
>>> 
>>> Things aren’t much better for the shared sub-systems.  If there was 
>>> something compelling that needed to be done on the shared sub-system

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

Of course we do not have a huge community. But a very long lasting one. And 
there is not really standstill. There have been 64 committs in the last 3 
monts. This is actually not too bad!

So how to move on?

Who wants to remain active in the PMC? Who wants to leave?

We already pinned down the parts where there certainly IS community. 
In addition to that I would like to bring in Geronimo-Config  as an 
implementation of the Microprofile-Config specification.
Discussions have been going on last year all work has been done by me on my 
github account. But would love to bring it over here.

I'll dig the old projects charter and try to kick off a reboot together with 
Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have a 
helping hand from time to time. Note that everyone is welcome, even if he 
currently has no time to commit but only wants to provide guide and feedback.

The first step I recommend is be to merge various mailing lists together.
Then we need to verify the charter and probably tweak it for the new goal.
We also need to communicate that we do not further maintain the Geronimo Server 
parts.

Any objection?

LieGrue,
strub


> Am 13.03.2017 um 20:46 schrieb Kevan Miller :
> 
> "need" and "in use" does not necessarily translate into community. The need 
> for the geronimo components that have been discussed is not new. As far as I 
> can tell, so far, that has not translated into a community. 
> 
> If we want to continue the project, demonstrate the community that is needed 
> for the project to continue. As I stated previously, a good starting point: 
> create a new charter for the project, identify active PMC members/committers, 
> and obtain board approval. 
> 
> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:
> Hi Alan!
> 
> There are quite a few things which fit into this scenario imo.
> 
> I think we really miss some 'toolbox project' for EE components at the ASF.
> There was a tendency to make all those projects own TLPs for some time. But 
> that approach simply doesn't scale, and we end up with the same people in 
> most of those projects anyway.
> So moving the ones with lower activity into a common TLP would solve this 
> problem. Geronimo could probably become this project.
> 
> There are a lot old EE folks around which have tremendous knowledge. And 
> there are certain technologies which are really cool, but have the classical 
> EE-lifecycle up-down in terms of activity.
> That + the already existing components could be a great chance.
> 
> As you already said yourself: the terms of the big fat EE servers is over. 
> But nevertheless the technology and requirement behind most of the single 
> parts is still valid and often unbeaten.
> But nowadays it's more about making it easy to plug & play those technology 
> libs together more freely as they are needed. Thus moving the focus on 
> maintaining the components and not the server could be really appreciated by 
> the community.
> 
> You said there will be community if there is a need. I fully agree, and even 
> more I see a need for those parts.
> 
> LieGrue,
> strub
> 
> > Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
> >
> > After a good night’s sleep, I re-read this thread and I’ll respond without 
> > trying to guide you in where and how you decide to go with your efforts; 
> > thanks in advance for letting me reboot my reply.  :)
> >
> > Any pivot that this community decides upon, will have to be justified to 
> > the ASF board.  We will need to explain what will be different and justify 
> > how it will generate sustainable community activity.  With regards to that, 
> > I have two general concerns:
> >   • Will this this specific endeavor generate any new sustainable 
> > community activity?
> >   • Will any new activity of this specific endeavor represent activity 
> > that is unique to Geronimo or are we doing the chores of other projects to 
> > provide the appearance of activity?
> > The current level activity, is due to spec maintenance for downstream 
> > dependencies and we must admit that it is quite low.  Being an upstream 
> > “aggregator” does not provide appreciable added value at the cost of the 
> > doubled administration.  The specter of duplicate work will, in reality, 
> > never arise; this de facto efficiency is due to the awesomeness of the ASL 
> > 2.0 license.  The case for being an aggregator weakens even more given the 
> > fact that there just isn't a lot of work involved in maintaining specs.
> >
> > Things aren’t much better for the shared sub-systems.  If there was 
> > something compelling that needed to be done on the shared sub-systems, it 
> > would have been begun already; given the industry’s penchant for greenfield 
> > development (NIH) I doubt they will ever be revamped.
> >
> > This is why I went on my “need” soapbox.  Some new need must be found for 
> > Geronimo to provide.
> >
> >
> > Regards,
> > Alan
> >
> >
> >> On Mar 9, 2017, at 8:49 AM, R

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

"need" and "in use" does not necessarily translate into community. The need
for the geronimo components that have been discussed is not new. As far as
I can tell, so far, that has not translated into a community.

If we want to continue the project, demonstrate the community that is
needed for the project to continue. As I stated previously, a good starting
point: create a new charter for the project, identify active PMC
members/committers, and obtain board approval.

On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg  wrote:

> Hi Alan!
>
> There are quite a few things which fit into this scenario imo.
>
> I think we really miss some 'toolbox project' for EE components at the ASF.
> There was a tendency to make all those projects own TLPs for some time.
> But that approach simply doesn't scale, and we end up with the same people
> in most of those projects anyway.
> So moving the ones with lower activity into a common TLP would solve this
> problem. Geronimo could probably become this project.
>
> There are a lot old EE folks around which have tremendous knowledge. And
> there are certain technologies which are really cool, but have the
> classical EE-lifecycle up-down in terms of activity.
> That + the already existing components could be a great chance.
>
> As you already said yourself: the terms of the big fat EE servers is over.
> But nevertheless the technology and requirement behind most of the single
> parts is still valid and often unbeaten.
> But nowadays it's more about making it easy to plug & play those
> technology libs together more freely as they are needed. Thus moving the
> focus on maintaining the components and not the server could be really
> appreciated by the community.
>
> You said there will be community if there is a need. I fully agree, and
> even more I see a need for those parts.
>
> LieGrue,
> strub
>
> > Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
> >
> > After a good night’s sleep, I re-read this thread and I’ll respond
> without trying to guide you in where and how you decide to go with your
> efforts; thanks in advance for letting me reboot my reply.  :)
> >
> > Any pivot that this community decides upon, will have to be justified to
> the ASF board.  We will need to explain what will be different and justify
> how it will generate sustainable community activity.  With regards to that,
> I have two general concerns:
> >   • Will this this specific endeavor generate any new sustainable
> community activity?
> >   • Will any new activity of this specific endeavor represent
> activity that is unique to Geronimo or are we doing the chores of other
> projects to provide the appearance of activity?
> > The current level activity, is due to spec maintenance for downstream
> dependencies and we must admit that it is quite low.  Being an upstream
> “aggregator” does not provide appreciable added value at the cost of the
> doubled administration.  The specter of duplicate work will, in reality,
> never arise; this de facto efficiency is due to the awesomeness of the ASL
> 2.0 license.  The case for being an aggregator weakens even more given the
> fact that there just isn't a lot of work involved in maintaining specs.
> >
> > Things aren’t much better for the shared sub-systems.  If there was
> something compelling that needed to be done on the shared sub-systems, it
> would have been begun already; given the industry’s penchant for greenfield
> development (NIH) I doubt they will ever be revamped.
> >
> > This is why I went on my “need” soapbox.  Some new need must be found
> for Geronimo to provide.
> >
> >
> > Regards,
> > Alan
> >
> >
> >> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau 
> wrote:
> >>
> >> I have quite a hard time to understand why it is an issue having a
> project led by the aggregation of others and not by itself? Assume one sec
> we close Geronimo or it doesnt exist, then we'll move the bit of code in
> one of the project - let say tomee - and tomee will becomes the exact same
> kind of project. The alternative is to split in a lot of small projects but
> as mentionned a lot of overlap is in these projects in term of forces and
> it doesn't work really better, it just multiply the work load for each
> contributor. That's why I think G is not a bad solution as it is today.
> Scope surely needs to be refined like Mark started to do and objectives are
> clearly a bit different than a project pushing its own server/solution but
> I think there is a space for it and for Apache I think it is saner this way.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-09 17:01 GMT+01:00 Alan Cabrera :
> >> It has been my personal experience that need is the catalyst for a
> vibrant OSS project.  The product and community spring forth from that.
> Adopting an “if we build it they will come” tactic does not usually result
> in success.  Rather than rummaging through the trunk to see what bits
> peo

Re: Discuss: Move Geronimo to Attic

[Kevin Sutter]

I've been on vacation, so this was an interesting conversation to come home
to...  :-)  I'm not a member of the Geronimo PMC, but I've been monitoring
the activity with Geronimo for years.  Thus, I have no "voting" capability,
but I do have an interest...

I like the analysis that Mark started with who is dependent on the various
parts of Geronimo -- specs, apis, impls.  We probably need to expand on
that to include external dependencies as well.  For example, David
mentioned that IBM is currently using the Yoko orb.  Not that it should
matter if an external entity has a dependency, but it might demonstrate
some potential community involvement.

I like the idea of an "ee-commons" type of project to contain the pieces of
Geronimo that are currently in use by other projects.  I suppose another
idea is to just move these common pieces of code to the respective
projects.  For example, move the JPA specs to OpenJPA.

I'm also surprised that TomEE isn't more active in this conversation.  I
would guess that they have several dependencies on various pieces of
Geronimo.  I suppose that's another idea -- maybe the common pieces of code
could be moved to TomEE?  Not trying to dump on that project, but they
might be the most active project using these pieces.

Just my two cents worth...
Kevin

On Sun, Mar 12, 2017 at 2:01 PM, Mark Struberg  wrote:

> Hi Alan!
>
> There are quite a few things which fit into this scenario imo.
>
> I think we really miss some 'toolbox project' for EE components at the ASF.
> There was a tendency to make all those projects own TLPs for some time.
> But that approach simply doesn't scale, and we end up with the same people
> in most of those projects anyway.
> So moving the ones with lower activity into a common TLP would solve this
> problem. Geronimo could probably become this project.
>
> There are a lot old EE folks around which have tremendous knowledge. And
> there are certain technologies which are really cool, but have the
> classical EE-lifecycle up-down in terms of activity.
> That + the already existing components could be a great chance.
>
> As you already said yourself: the terms of the big fat EE servers is over.
> But nevertheless the technology and requirement behind most of the single
> parts is still valid and often unbeaten.
> But nowadays it's more about making it easy to plug & play those
> technology libs together more freely as they are needed. Thus moving the
> focus on maintaining the components and not the server could be really
> appreciated by the community.
>
> You said there will be community if there is a need. I fully agree, and
> even more I see a need for those parts.
>
> LieGrue,
> strub
>
> > Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
> >
> > After a good night’s sleep, I re-read this thread and I’ll respond
> without trying to guide you in where and how you decide to go with your
> efforts; thanks in advance for letting me reboot my reply.  :)
> >
> > Any pivot that this community decides upon, will have to be justified to
> the ASF board.  We will need to explain what will be different and justify
> how it will generate sustainable community activity.  With regards to that,
> I have two general concerns:
> >   • Will this this specific endeavor generate any new sustainable
> community activity?
> >   • Will any new activity of this specific endeavor represent
> activity that is unique to Geronimo or are we doing the chores of other
> projects to provide the appearance of activity?
> > The current level activity, is due to spec maintenance for downstream
> dependencies and we must admit that it is quite low.  Being an upstream
> “aggregator” does not provide appreciable added value at the cost of the
> doubled administration.  The specter of duplicate work will, in reality,
> never arise; this de facto efficiency is due to the awesomeness of the ASL
> 2.0 license.  The case for being an aggregator weakens even more given the
> fact that there just isn't a lot of work involved in maintaining specs.
> >
> > Things aren’t much better for the shared sub-systems.  If there was
> something compelling that needed to be done on the shared sub-systems, it
> would have been begun already; given the industry’s penchant for greenfield
> development (NIH) I doubt they will ever be revamped.
> >
> > This is why I went on my “need” soapbox.  Some new need must be found
> for Geronimo to provide.
> >
> >
> > Regards,
> > Alan
> >
> >
> >> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau 
> wrote:
> >>
> >> I have quite a hard time to understand why it is an issue having a
> project led by the aggregation of others and not by itself? Assume one sec
> we close Geronimo or it doesnt exist, then we'll move the bit of code in
> one of the project - let say tomee - and tomee will becomes the exact same
> kind of project. The alternative is to split in a lot of small projects but
> as mentionned a lot of overlap is in these projects in term of forces and
> it doesn't

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

Hi Alan!

There are quite a few things which fit into this scenario imo.

I think we really miss some 'toolbox project' for EE components at the ASF.
There was a tendency to make all those projects own TLPs for some time. But 
that approach simply doesn't scale, and we end up with the same people in most 
of those projects anyway. 
So moving the ones with lower activity into a common TLP would solve this 
problem. Geronimo could probably become this project. 

There are a lot old EE folks around which have tremendous knowledge. And there 
are certain technologies which are really cool, but have the classical 
EE-lifecycle up-down in terms of activity.
That + the already existing components could be a great chance.

As you already said yourself: the terms of the big fat EE servers is over. But 
nevertheless the technology and requirement behind most of the single parts is 
still valid and often unbeaten. 
But nowadays it's more about making it easy to plug & play those technology 
libs together more freely as they are needed. Thus moving the focus on 
maintaining the components and not the server could be really appreciated by 
the community.

You said there will be community if there is a need. I fully agree, and even 
more I see a need for those parts.

LieGrue,
strub

> Am 12.03.2017 um 19:15 schrieb Alan Cabrera :
> 
> After a good night’s sleep, I re-read this thread and I’ll respond without 
> trying to guide you in where and how you decide to go with your efforts; 
> thanks in advance for letting me reboot my reply.  :)
> 
> Any pivot that this community decides upon, will have to be justified to the 
> ASF board.  We will need to explain what will be different and justify how it 
> will generate sustainable community activity.  With regards to that, I have 
> two general concerns:
>   • Will this this specific endeavor generate any new sustainable 
> community activity? 
>   • Will any new activity of this specific endeavor represent activity 
> that is unique to Geronimo or are we doing the chores of other projects to 
> provide the appearance of activity?
> The current level activity, is due to spec maintenance for downstream 
> dependencies and we must admit that it is quite low.  Being an upstream 
> “aggregator” does not provide appreciable added value at the cost of the 
> doubled administration.  The specter of duplicate work will, in reality, 
> never arise; this de facto efficiency is due to the awesomeness of the ASL 
> 2.0 license.  The case for being an aggregator weakens even more given the 
> fact that there just isn't a lot of work involved in maintaining specs.
> 
> Things aren’t much better for the shared sub-systems.  If there was something 
> compelling that needed to be done on the shared sub-systems, it would have 
> been begun already; given the industry’s penchant for greenfield development 
> (NIH) I doubt they will ever be revamped.
> 
> This is why I went on my “need” soapbox.  Some new need must be found for 
> Geronimo to provide.
> 
> 
> Regards,
> Alan
> 
> 
>> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau  wrote:
>> 
>> I have quite a hard time to understand why it is an issue having a project 
>> led by the aggregation of others and not by itself? Assume one sec we close 
>> Geronimo or it doesnt exist, then we'll move the bit of code in one of the 
>> project - let say tomee - and tomee will becomes the exact same kind of 
>> project. The alternative is to split in a lot of small projects but as 
>> mentionned a lot of overlap is in these projects in term of forces and it 
>> doesn't work really better, it just multiply the work load for each 
>> contributor. That's why I think G is not a bad solution as it is today. 
>> Scope surely needs to be refined like Mark started to do and objectives are 
>> clearly a bit different than a project pushing its own server/solution but I 
>> think there is a space for it and for Apache I think it is saner this way.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> 
>> 2017-03-09 17:01 GMT+01:00 Alan Cabrera :
>> It has been my personal experience that need is the catalyst for a vibrant 
>> OSS project.  The product and community spring forth from that.  Adopting an 
>> “if we build it they will come” tactic does not usually result in success.  
>> Rather than rummaging through the trunk to see what bits people might be 
>> attracted to, maybe it might be better to look at the existing JEE-related 
>> OSS communities out there and ask “what need are they not fulfilling?”
>> 
>> That would answer passersby’s questions of “why would I be interested in 
>> this project?”  
>> 
>> That would be a slam dunk to present to the ASF board, “Geronimo is now 
>> focused on fulfilling a new need, X”.
>> 
>> What unfulfilled need is out there?
>> 
>> 
>> Regards,
>> Alan
>> 
>> 
>> 
>>> On Mar 9, 2017, at 7:04 AM, Mark Struberg  wrote:
>>> 
>>> I totally agree.
>>> 
>>> But intere

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

After a good night’s sleep, I re-read this thread and I’ll respond without 
trying to guide you in where and how you decide to go with your efforts; thanks 
in advance for letting me reboot my reply.  :)

Any pivot that this community decides upon, will have to be justified to the 
ASF board.  We will need to explain what will be different and justify how it 
will generate sustainable community activity.  With regards to that, I have two 
general concerns:
Will this this specific endeavor generate any new sustainable community 
activity? 
Will any new activity of this specific endeavor represent activity that is 
unique to Geronimo or are we doing the chores of other projects to provide the 
appearance of activity?
The current level activity, is due to spec maintenance for downstream 
dependencies and we must admit that it is quite low.  Being an upstream 
“aggregator” does not provide appreciable added value at the cost of the 
doubled administration.  The specter of duplicate work will, in reality, never 
arise; this de facto efficiency is due to the awesomeness of the ASL 2.0 
license.  The case for being an aggregator weakens even more given the fact 
that there just isn't a lot of work involved in maintaining specs.

Things aren’t much better for the shared sub-systems.  If there was something 
compelling that needed to be done on the shared sub-systems, it would have been 
begun already; given the industry’s penchant for greenfield development (NIH) I 
doubt they will ever be revamped.

This is why I went on my “need” soapbox.  Some new need must be found for 
Geronimo to provide.


Regards,
Alan


> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau  wrote:
> 
> I have quite a hard time to understand why it is an issue having a project 
> led by the aggregation of others and not by itself? Assume one sec we close 
> Geronimo or it doesnt exist, then we'll move the bit of code in one of the 
> project - let say tomee - and tomee will becomes the exact same kind of 
> project. The alternative is to split in a lot of small projects but as 
> mentionned a lot of overlap is in these projects in term of forces and it 
> doesn't work really better, it just multiply the work load for each 
> contributor. That's why I think G is not a bad solution as it is today. Scope 
> surely needs to be refined like Mark started to do and objectives are clearly 
> a bit different than a project pushing its own server/solution but I think 
> there is a space for it and for Apache I think it is saner this way.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | JavaEE Factory 
> 
> 2017-03-09 17:01 GMT+01:00 Alan Cabrera  >:
> It has been my personal experience that need is the catalyst for a vibrant 
> OSS project.  The product and community spring forth from that.  Adopting an 
> “if we build it they will come” tactic does not usually result in success.  
> Rather than rummaging through the trunk to see what bits people might be 
> attracted to, maybe it might be better to look at the existing JEE-related 
> OSS communities out there and ask “what need are they not fulfilling?”
> 
> That would answer passersby’s questions of “why would I be interested in this 
> project?”  
> 
> That would be a slam dunk to present to the ASF board, “Geronimo is now 
> focused on fulfilling a new need, X”.
> 
> What unfulfilled need is out there?
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 9, 2017, at 7:04 AM, Mark Struberg > > wrote:
>> 
>> I totally agree.
>> 
>> But interest from the community is always a product of a good product and 
>> feature roadmap.
>> Without any good product you will not be able to build a sustainable 
>> community around it.
>> 
>> Of course there are many things which can trash a community despite a good 
>> product. But without product there is no community.
>> At the end we are not here only because the people are great, but because we 
>> see a benefit in the product we create in this project - AND the people are 
>> great ;)
>> 
>> So my first goal was to identify the features which might be of interest.
>> The next step is to check whether there is enough community interest in 
>> those features or whether we could move then to another community. Ideally 
>> with still using the org.apache.geronimo groupId and packages. Otherwise it 
>> would be quite some problem for the users.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 09.03.2017 um 14:46 schrieb Alex Karasulu >> >:
>>> 
>>> I think more important than whether or not JEE is popular (or whatever 
>>> along those lines), are the questions about community health and is the PMC 
>>> still capable of fulfilling its du

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

I’m not opposed to aggregation, per se.  I’m just trying to point out a 
possibly different way of jumpstarting community activity, a different way of 
searching for a new direction for Geronimo.

It’s different than doing an inventory of stuff we have and thinking, “how can 
we make this stuff more enticing to people?”  An inventory is good, but make 
sure that it’s not an inventory of deck chairs on the Titanic.  Collecting such 
an inventory may just be busywork, and a bit premature, without the the goal of 
fulfilling a specific need to provide direction.  The inventory of stuff as a 
starting point may blind one to other possibilities for Geronimo.

Elucidating the need comes first.  The enumerating features to fulfill that 
need comes second.  Once that is known it will help provide direction as to 
what parts of Geronimo are relevant and what aren’t, what parts need to be 
spruced up and what parts are fine as is.

Think BIG!

I have one idea.  It’s something that I don’t think has been done yet, at least 
to the extent that it’s been done at LinkedIn, and it fulfills a dire need.  

The management of runtime-configurations for heterogeneous global environments. 
 At LinkedIn, we treat runtime properties like code.  Not just in the sense of 
a “source code repository”, but also in the sense that services can declare 
what properties they consume and the CI/CD pipeline will prevent those 
properties from being borked.  This is very handy when properties are shared 
amongst multiple services across multiple fabrics.  It also does constraint 
checking to make sure properties adhere to certain constraints that can be set 
at the component code level, service level, and “SRE level”.

Such a system can provide visibility as to what properties are being used, not 
being used, or need to be provided before rolling a service into a new 
fabric/edge.

It fulfills a need for what is usually given little thought as a service is 
tossed over the wall for an SRE to contend with.  It forces early conversations 
between the component provider and the service owner.  It forces early 
conversations between a service owner and the SRE, before deployment.  It 
forces component and service owners to diligently consider how their products 
will be managed out in the field, possibly before code is even cut, and 
globally enforces those runtime contracts throughout the lifetime of that 
product in the CI/CD pipeline.

So, this isn’t just JEE.  This is JEE, Play, ATS, Docker, Rails, Httpd, NodeJS, 
Hadoop, …

This isn’t just services.  This is the CI/CD pipeline of Jenkins, Travis, …

Well, that’s it.  One idea to consider.


Regards,
Alan

> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau  wrote:
> 
> I have quite a hard time to understand why it is an issue having a project 
> led by the aggregation of others and not by itself? Assume one sec we close 
> Geronimo or it doesnt exist, then we'll move the bit of code in one of the 
> project - let say tomee - and tomee will becomes the exact same kind of 
> project. The alternative is to split in a lot of small projects but as 
> mentionned a lot of overlap is in these projects in term of forces and it 
> doesn't work really better, it just multiply the work load for each 
> contributor. That's why I think G is not a bad solution as it is today. Scope 
> surely needs to be refined like Mark started to do and objectives are clearly 
> a bit different than a project pushing its own server/solution but I think 
> there is a space for it and for Apache I think it is saner this way.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | JavaEE Factory 
> 
> 2017-03-09 17:01 GMT+01:00 Alan Cabrera  >:
> It has been my personal experience that need is the catalyst for a vibrant 
> OSS project.  The product and community spring forth from that.  Adopting an 
> “if we build it they will come” tactic does not usually result in success.  
> Rather than rummaging through the trunk to see what bits people might be 
> attracted to, maybe it might be better to look at the existing JEE-related 
> OSS communities out there and ask “what need are they not fulfilling?”
> 
> That would answer passersby’s questions of “why would I be interested in this 
> project?”  
> 
> That would be a slam dunk to present to the ASF board, “Geronimo is now 
> focused on fulfilling a new need, X”.
> 
> What unfulfilled need is out there?
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 9, 2017, at 7:04 AM, Mark Struberg > > wrote:
>> 
>> I totally agree.
>> 
>> But interest from the community is always a product of a good product and 
>> feature roadmap.
>> Without any good product you will not be 

Re: Discuss: Move Geronimo to Attic

[Romain Manni-Bucau]

I have quite a hard time to understand why it is an issue having a project
led by the aggregation of others and not by itself? Assume one sec we close
Geronimo or it doesnt exist, then we'll move the bit of code in one of the
project - let say tomee - and tomee will becomes the exact same kind of
project. The alternative is to split in a lot of small projects but as
mentionned a lot of overlap is in these projects in term of forces and it
doesn't work really better, it just multiply the work load for each
contributor. That's why I think G is not a bad solution as it is today.
Scope surely needs to be refined like Mark started to do and objectives are
clearly a bit different than a project pushing its own server/solution but
I think there is a space for it and for Apache I think it is saner this way.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-03-09 17:01 GMT+01:00 Alan Cabrera :

> It has been my personal experience that *need* is the catalyst for a
> vibrant OSS project.  The product and community spring forth from that.
> Adopting an “if we build it they will come” tactic does not usually result
> in success.  Rather than rummaging through the trunk to see what bits
> people might be attracted to, maybe it might be better to look at the
> existing JEE-related OSS communities out there and ask “what need are they
> not fulfilling?”
>
> That would answer passersby’s questions of “why would I be interested in
> this project?”
>
> That would be a slam dunk to present to the ASF board, “Geronimo is now
> focused on fulfilling a new need, X”.
>
> What unfulfilled need is out there?
>
>
> Regards,
> Alan
>
>
>
> On Mar 9, 2017, at 7:04 AM, Mark Struberg  wrote:
>
> I totally agree.
>
> But interest from the community is always a product of a good product and
> feature roadmap.
> Without any good product you will not be able to build a sustainable
> community around it.
>
> Of course there are many things which can trash a community despite a good
> product. But without product there is no community.
> At the end we are not here only because the people are great, but because
> we see a benefit in the product we create in this project - AND the people
> are great ;)
>
> So my first goal was to identify the features which might be of interest.
> The next step is to check whether there is enough community interest in
> those features or whether we could move then to another community. Ideally
> with still using the org.apache.geronimo groupId and packages. Otherwise it
> would be quite some problem for the users.
>
> LieGrue,
> strub
>
> Am 09.03.2017 um 14:46 schrieb Alex Karasulu :
>
> I think more important than whether or not JEE is popular (or whatever
> along those lines), are the questions about community health and is the PMC
> still capable of fulfilling its duties.
>
> My 2 cents,
> --Alex
>
> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:
> Romain and I went through the Geronimo SVN and made a list of which
> components are used by other projects.
>
>
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> https://svn.apache.org/repos/asf/geronimo/components/txmanager
>• TomEE (txmgr+connector)
>• Meecrowave (txmgr)
>• Aries (txmgr)
>
> https://svn.apache.org/repos/asf/geronimo/components/
> geronimo-schema-javaee_6
>
> https://svn.apache.org/repos/asf/geronimo/genesis/
>• Maven parents for geronimo-specs
>
> https://svn.apache.org/repos/asf/geronimo/javamail/
>• TomEE as delivery
>• Lot of standalone
>• -> we can ask Hendrik pby
>
> https://svn.apache.org/repos/asf/geronimo/specs/
>• TomEE
>• OpenWebBeans
>• Meecrowave
>• OpenJPA
>• Johnzon
>• BatchEE
>• Karaf
>• Aries
>• Tons of external customer projects which don’t want to use some
> official javax jars due to licensing concerns
>
> https://svn.apache.org/repos/asf/geronimo/xbean/
>• TomEE
>• OpenWebBeans
>• Meecrowave
>• Aries
>• Karaf
>• OpenJPA
>• CXF (supported)
>
> Osgi-locator too but guess this one can drop and belong to karaf or
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>
>
> I've created a google doc. Just ping me if you want to edit something and
> I'll share it.
>
> David, you mentioned JASPIC. I could not find that even. Is this inside
> the geronimo-server probably?
> Are there other gems which are not maintained as components but just
> inside geronimo?
>
> txs and LieGrue,
> strub
>
>
> Am 09.03.2017 um 08:44 schrieb David Jencks :
>
> I go back and forth on 

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

It has been my personal experience that need is the catalyst for a vibrant OSS 
project.  The product and community spring forth from that.  Adopting an “if we 
build it they will come” tactic does not usually result in success.  Rather 
than rummaging through the trunk to see what bits people might be attracted to, 
maybe it might be better to look at the existing JEE-related OSS communities 
out there and ask “what need are they not fulfilling?”

That would answer passersby’s questions of “why would I be interested in this 
project?”  

That would be a slam dunk to present to the ASF board, “Geronimo is now focused 
on fulfilling a new need, X”.

What unfulfilled need is out there?


Regards,
Alan



> On Mar 9, 2017, at 7:04 AM, Mark Struberg  wrote:
> 
> I totally agree.
> 
> But interest from the community is always a product of a good product and 
> feature roadmap.
> Without any good product you will not be able to build a sustainable 
> community around it.
> 
> Of course there are many things which can trash a community despite a good 
> product. But without product there is no community.
> At the end we are not here only because the people are great, but because we 
> see a benefit in the product we create in this project - AND the people are 
> great ;)
> 
> So my first goal was to identify the features which might be of interest.
> The next step is to check whether there is enough community interest in those 
> features or whether we could move then to another community. Ideally with 
> still using the org.apache.geronimo groupId and packages. Otherwise it would 
> be quite some problem for the users.
> 
> LieGrue,
> strub
> 
>> Am 09.03.2017 um 14:46 schrieb Alex Karasulu :
>> 
>> I think more important than whether or not JEE is popular (or whatever along 
>> those lines), are the questions about community health and is the PMC still 
>> capable of fulfilling its duties.
>> 
>> My 2 cents,
>> --Alex
>> 
>> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:
>> Romain and I went through the Geronimo SVN and made a list of which 
>> components are used by other projects.
>> 
>> 
>> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>> 
>> https://svn.apache.org/repos/asf/geronimo/KEYS
>> 
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager
>>• TomEE (txmgr+connector)
>>• Meecrowave (txmgr)
>>• Aries (txmgr)
>> 
>> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6
>> 
>> https://svn.apache.org/repos/asf/geronimo/genesis/
>>• Maven parents for geronimo-specs
>> 
>> https://svn.apache.org/repos/asf/geronimo/javamail/
>>• TomEE as delivery
>>• Lot of standalone
>>• -> we can ask Hendrik pby
>> 
>> https://svn.apache.org/repos/asf/geronimo/specs/
>>• TomEE
>>• OpenWebBeans
>>• Meecrowave
>>• OpenJPA
>>• Johnzon
>>• BatchEE
>>• Karaf
>>• Aries
>>• Tons of external customer projects which don’t want to use some 
>> official javax jars due to licensing concerns
>> 
>> https://svn.apache.org/repos/asf/geronimo/xbean/
>>• TomEE
>>• OpenWebBeans
>>• Meecrowave
>>• Aries
>>• Karaf
>>• OpenJPA
>>• CXF (supported)
>> 
>> Osgi-locator too but guess this one can drop and belong to karaf or 
>> servicemix.
>> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>> 
>> 
>> I've created a google doc. Just ping me if you want to edit something and 
>> I'll share it.
>> 
>> David, you mentioned JASPIC. I could not find that even. Is this inside the 
>> geronimo-server probably?
>> Are there other gems which are not maintained as components but just inside 
>> geronimo?
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>>> Am 09.03.2017 um 08:44 schrieb David Jencks :
>>> 
>>> I go back and forth on whether to shut G down completely.  Perhaps it would 
>>> be useful to inventory which parts are used by which other projects? Off 
>>> the top of my head….
>>> 
>>> Specs …. who uses G’s and who has their own?
>>> 
>>> Components…. I think there are several users of the transaction manager, I 
>>> don’t know about the connector framework, and I’m pretty sure no one uses 
>>> my jaspic implementation.  The TM is stable but now that faster than 
>>> spinning rust persistent memory is popular the logger could probably be 
>>> rewritten to be much faster.
>>> 
>>> xbean …. tomee I believe, anyone else?  Does activemq still use 
>>> xbean-spring?  Knowing more about osgi now I might be able to gets 
>>> xbean-blueprint to work:-)
>>> 
>>> yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
>>> and start contributing.
>>> 
>>> Any other bits being used?
>>> 
>>> If we kept G around in a reduced state, how will we maintain enough 
>>> interest to file the board reports?  Some days  I think I might have enough 
>>> interest and some days not.
>>> 
>>> If w

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

> On Mar 8, 2017, at 10:44 AM, Mark Struberg  wrote:
> 
> Alan, I understand that you don't want to put much more energy into this 
> project. That is totally understandable and fine. 
> But while you are PMC chair you still cannot declare that the project is dead 
> as long as there are enough PMC members still active to keep the project 
> going.

Let me be perfectly clear.  I am not declaring this project dead.  I have 
started a long delayed public discussion about possibly moving Geronimo to the 
Attic.  We’ve had this discussion many times over the years on the private PMC 
list, out of concern of spooking potential public interest.  Now, I am 
declaring that it’s time to discuss this publicly; my opening of the discussion 
to the public spurred at the request of an ASF board member.

The questions you ask below, have they not already been asked, privately and 
publicly, multiple times over the past half decade?  Can you provide your 
opinion as to how many more unanswered calls to action must take place before 
the project can feel comfortable donating the used bits of Geronimo to the 
active OSS projects that actually use them?  Before the project embarks on yet 
another SOS it is important to know what is your concrete criteria that the 
project can use to honestly declare to the ASF board and corporate members that 
there is an active community here.  It is also important to know what is your 
concrete criteria for deciding that a reasonable effort has been made and it’s 
time to wind down.  Keep in mind that both criteria can be applied to what 
efforts and results have already taken place over the past decade.  Details as 
to what is different from this effort from what has been done in the past would 
be helpful to garner consensus.

These are not hard requirements being dictated by me, but a suggestion to 
prepare us for what will inevitably be asked of us should the project soldier 
on.  In addition to a consensus that an effort should be made, there should be 
a consensus on clear and transparent criteria for failure as well as success.

> Before we dump the project I suggest we start with an analysis of where we 
> are right now.
> 
> What about starting look into
> .) Who is still active and willing to continue Geronimo as a ee-commons 
> project?
> .) Which project parts of the project are of some shared interest and might 
> be good to get some maintenance love and some realistic chance that this is 
> gonna happening?
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 08.03.2017 um 16:38 schrieb Alan Cabrera :
>> 
>> I agree and I even acknowledged that below, but what I feel Mark and you are 
>> not acknowledging is that the interest/activity is for a smaller subset of 
>> JEE.  Of that subset, even you list the OSS projects that are supporting the 
>> JEE bits that are still relevant.  They have active communities and are even 
>> likely to be using our implementation of our specs, but that is not 
>> reflective of the viability of Geronimo as an active JEE project at the ASF. 
>> 
>> Let us keep in mind that the raison d’être of Geronimo is the complete 
>> implementation of the JEE standard.  The JEE spec licensing that the project 
>> is bound to goes through excruciating lengths to make sure that the spec is 
>> implemented in toto and not piecemeal.  Given that the overwhelming bulk of 
>> the code is simply an inclusion of external OSS projects, when the existing 
>> active OSS projects are factored out there’s not a lot left.  There’s no 
>> denying that much of what’s left is good technology.  It’s just not enough 
>> to jumpstart a new active OSS community.  And this is the crux of the 
>> matter, community.
>> 
>> Does Geronimo still have good technology? Yes.
>> 
>> When one factors out the existing OSS overlap, is it enough to jumpstart a 
>> new active community?  No.
>> 
>> A few engineers applying patches once a year is not an active community.  To 
>> be sure the downstream OSS projects are appreciative.  However, what’s the 
>> point?  The engineering activity here is really a proxy for other OSS 
>> projects and not indicative of the viability of Geronimo as an active ASF 
>> project.  Things get fixed and released, but in the end the wider community 
>> goes to the other OSS projects to consume those artifacts.
>> 
>> Geronimo had a great run.  It made significant contributions to the 
>> industry.  However, the relevancy of the JEE spec has wained and the dearth 
>> of activity is concrete proof of that.
>> 
>> With that said, this does not prevent a set of enterprising engineers with 
>> “can do” attitudes to pick over the bones that are in the Attic and create 
>> another application server.  But that effort, IMO, will need to be borne in 
>> the Incubator.
>> 
>> 
>> Regards,
>> Alan
>> 
>> 
>>> On Mar 8, 2017, at 1:34 AM, Romain Manni-Bucau  
>>> wrote:
>>> 
>>> I share that vision (the one of Mark).
>>> 
>>> The ee-commons part is really used and still active (even i

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

+1

> On Mar 9, 2017, at 5:46 AM, Alex Karasulu  wrote:
> 
> I think more important than whether or not JEE is popular (or whatever along 
> those lines), are the questions about community health and is the PMC still 
> capable of fulfilling its duties.
> 
> My 2 cents,
> --Alex
> 
> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  > wrote:
> Romain and I went through the Geronimo SVN and made a list of which 
> components are used by other projects.
> 
> 
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/ 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/components/txmanager 
> 
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
> 
> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/genesis/ 
> 
> • Maven parents for geronimo-specs
> 
> https://svn.apache.org/repos/asf/geronimo/javamail/ 
> 
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
> 
> https://svn.apache.org/repos/asf/geronimo/specs/ 
> 
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some 
> official javax jars due to licensing concerns
> 
> https://svn.apache.org/repos/asf/geronimo/xbean/ 
> 
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
> 
> Osgi-locator too but guess this one can drop and belong to karaf or 
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
> 
> 
> I've created a google doc. Just ping me if you want to edit something and 
> I'll share it.
> 
> David, you mentioned JASPIC. I could not find that even. Is this inside the 
> geronimo-server probably?
> Are there other gems which are not maintained as components but just inside 
> geronimo?
> 
> txs and LieGrue,
> strub
> 
> 
> > Am 09.03.2017 um 08:44 schrieb David Jencks  > >:
> >
> > I go back and forth on whether to shut G down completely.  Perhaps it would 
> > be useful to inventory which parts are used by which other projects? Off 
> > the top of my head….
> >
> > Specs …. who uses G’s and who has their own?
> >
> > Components…. I think there are several users of the transaction manager, I 
> > don’t know about the connector framework, and I’m pretty sure no one uses 
> > my jaspic implementation.  The TM is stable but now that faster than 
> > spinning rust persistent memory is popular the logger could probably be 
> > rewritten to be much faster.
> >
> > xbean …. tomee I believe, anyone else?  Does activemq still use 
> > xbean-spring?  Knowing more about osgi now I might be able to gets 
> > xbean-blueprint to work:-)
> >
> > yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
> > and start contributing.
> >
> > Any other bits being used?
> >
> > If we kept G around in a reduced state, how will we maintain enough 
> > interest to file the board reports?  Some days  I think I might have enough 
> > interest and some days not.
> >
> > If we did not shut down the whole project would we mark the removed bits 
> > (server primarily) as not being developed or move them to the attic?
> >
> > thanks
> > david jencks
> >
> >> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  >> > wrote:
> >>
> >> A valid point is activity related to G happens elsewhere, However 
> >> elsewhere is not "tomee" which would make things simple to move but A, B, 
> >> C so shutting down G is likely the easiest solution for G itself but also 
> >> the worse for all its dependent projects - and ASF consistency since G is 
> >> now seen as the owner of specs, xbean etcToday G is the result of 
> >> communities and I don't see it as a bad thing even if not common @ASF. It 
> >> allows new interactions with sometimes completely different area of 
> >> knowledge which is actually great and can't happen elsewhere IMHO (the 
> >> dead of G would mean fork per project probably).
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom  >> >:
> >> I’ve monitored G fo

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

I totally agree.

But interest from the community is always a product of a good product and 
feature roadmap.
Without any good product you will not be able to build a sustainable community 
around it.

Of course there are many things which can trash a community despite a good 
product. But without product there is no community.
At the end we are not here only because the people are great, but because we 
see a benefit in the product we create in this project - AND the people are 
great ;)

So my first goal was to identify the features which might be of interest.
The next step is to check whether there is enough community interest in those 
features or whether we could move then to another community. Ideally with still 
using the org.apache.geronimo groupId and packages. Otherwise it would be quite 
some problem for the users.

LieGrue,
strub

> Am 09.03.2017 um 14:46 schrieb Alex Karasulu :
> 
> I think more important than whether or not JEE is popular (or whatever along 
> those lines), are the questions about community health and is the PMC still 
> capable of fulfilling its duties.
> 
> My 2 cents,
> --Alex
> 
> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:
> Romain and I went through the Geronimo SVN and made a list of which 
> components are used by other projects.
> 
> 
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
> 
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> https://svn.apache.org/repos/asf/geronimo/components/txmanager
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
> 
> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6
> 
> https://svn.apache.org/repos/asf/geronimo/genesis/
> • Maven parents for geronimo-specs
> 
> https://svn.apache.org/repos/asf/geronimo/javamail/
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
> 
> https://svn.apache.org/repos/asf/geronimo/specs/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some 
> official javax jars due to licensing concerns
> 
> https://svn.apache.org/repos/asf/geronimo/xbean/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
> 
> Osgi-locator too but guess this one can drop and belong to karaf or 
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
> 
> 
> I've created a google doc. Just ping me if you want to edit something and 
> I'll share it.
> 
> David, you mentioned JASPIC. I could not find that even. Is this inside the 
> geronimo-server probably?
> Are there other gems which are not maintained as components but just inside 
> geronimo?
> 
> txs and LieGrue,
> strub
> 
> 
> > Am 09.03.2017 um 08:44 schrieb David Jencks :
> >
> > I go back and forth on whether to shut G down completely.  Perhaps it would 
> > be useful to inventory which parts are used by which other projects? Off 
> > the top of my head….
> >
> > Specs …. who uses G’s and who has their own?
> >
> > Components…. I think there are several users of the transaction manager, I 
> > don’t know about the connector framework, and I’m pretty sure no one uses 
> > my jaspic implementation.  The TM is stable but now that faster than 
> > spinning rust persistent memory is popular the logger could probably be 
> > rewritten to be much faster.
> >
> > xbean …. tomee I believe, anyone else?  Does activemq still use 
> > xbean-spring?  Knowing more about osgi now I might be able to gets 
> > xbean-blueprint to work:-)
> >
> > yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
> > and start contributing.
> >
> > Any other bits being used?
> >
> > If we kept G around in a reduced state, how will we maintain enough 
> > interest to file the board reports?  Some days  I think I might have enough 
> > interest and some days not.
> >
> > If we did not shut down the whole project would we mark the removed bits 
> > (server primarily) as not being developed or move them to the attic?
> >
> > thanks
> > david jencks
> >
> >> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  
> >> wrote:
> >>
> >> A valid point is activity related to G happens elsewhere, However 
> >> elsewhere is not "tomee" which would make things simple to move but A, B, 
> >> C so shutting down G is likely the easiest solution for G itself but also 
> >> the worse for all its dependent projects - and ASF consistency since G is 
> >> now seen as the owner of specs, xbean etcToday G is the result of 
> >> communities and I don't see it as a bad thing even if not common @ASF. It 
> >> allows new interactions with sometimes completely different area of 
> >> knowledge which is actually great and can't happen elsewhere IMHO (th

Re: Discuss: Move Geronimo to Attic

[Clebert Suconic]

ActiveMQ Artemis and ActiveMQ 5.x are using JMS and JMS 2.0

On Thu, Mar 9, 2017 at 4:08 AM, Mark Struberg  wrote:
> Romain and I went through the Geronimo SVN and made a list of which 
> components are used by other projects.
>
>
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> https://svn.apache.org/repos/asf/geronimo/components/txmanager
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
>
> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6
>
> https://svn.apache.org/repos/asf/geronimo/genesis/
> • Maven parents for geronimo-specs
>
> https://svn.apache.org/repos/asf/geronimo/javamail/
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
>
> https://svn.apache.org/repos/asf/geronimo/specs/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some 
> official javax jars due to licensing concerns
>
> https://svn.apache.org/repos/asf/geronimo/xbean/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
>
> Osgi-locator too but guess this one can drop and belong to karaf or 
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>
>
> I've created a google doc. Just ping me if you want to edit something and 
> I'll share it.
>
> David, you mentioned JASPIC. I could not find that even. Is this inside the 
> geronimo-server probably?
> Are there other gems which are not maintained as components but just inside 
> geronimo?
>
> txs and LieGrue,
> strub
>
>
>> Am 09.03.2017 um 08:44 schrieb David Jencks :
>>
>> I go back and forth on whether to shut G down completely.  Perhaps it would 
>> be useful to inventory which parts are used by which other projects? Off the 
>> top of my head….
>>
>> Specs …. who uses G’s and who has their own?
>>
>> Components…. I think there are several users of the transaction manager, I 
>> don’t know about the connector framework, and I’m pretty sure no one uses my 
>> jaspic implementation.  The TM is stable but now that faster than spinning 
>> rust persistent memory is popular the logger could probably be rewritten to 
>> be much faster.
>>
>> xbean …. tomee I believe, anyone else?  Does activemq still use 
>> xbean-spring?  Knowing more about osgi now I might be able to gets 
>> xbean-blueprint to work:-)
>>
>> yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
>> and start contributing.
>>
>> Any other bits being used?
>>
>> If we kept G around in a reduced state, how will we maintain enough interest 
>> to file the board reports?  Some days  I think I might have enough interest 
>> and some days not.
>>
>> If we did not shut down the whole project would we mark the removed bits 
>> (server primarily) as not being developed or move them to the attic?
>>
>> thanks
>> david jencks
>>
>>> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  
>>> wrote:
>>>
>>> A valid point is activity related to G happens elsewhere, However elsewhere 
>>> is not "tomee" which would make things simple to move but A, B, C so 
>>> shutting down G is likely the easiest solution for G itself but also the 
>>> worse for all its dependent projects - and ASF consistency since G is now 
>>> seen as the owner of specs, xbean etcToday G is the result of 
>>> communities and I don't see it as a bad thing even if not common @ASF. It 
>>> allows new interactions with sometimes completely different area of 
>>> knowledge which is actually great and can't happen elsewhere IMHO (the dead 
>>> of G would mean fork per project probably).
>>>
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>>
>>> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom :
>>> I’ve monitored G for several years since my departure.  For me, JEE is not 
>>> my main area of focus and as such, I’ve invested little time in the project 
>>> apart from reading the e-mail threads.  This is a community decision and 
>>> posting the discussion to dev@ is the right venue.
>>>
>>> As an inactive member I don’t have a strong vote, but, my observation is 
>>> that most of the community has moved on and there is little activity.  If 
>>> those that are still active want to keep going then God’s speed.
>>>
>>> Matt Hogstrom
>>> m...@hogstrom.org
>>> +1-919-656-0564
>>> PGP Key: 0x90ECB270
>>> Facebook  LinkedIn  Twitter
>>>
>>> "I’m smart enough to know how dumb I am."
>>> -  Hogstrom
>>>
>>>
>>>
 On Mar 9, 2017, at 08:47, Jason Dillon  wrote:

 On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de) wrote:
> Alan, I understand that you don't want to put much 

Re: Discuss: Move Geronimo to Attic

[Alex Karasulu]

I think more important than whether or not JEE is popular (or whatever
along those lines), are the questions about community health and is the PMC
still capable of fulfilling its duties.

My 2 cents,
--Alex

On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:

> Romain and I went through the Geronimo SVN and made a list of which
> components are used by other projects.
>
>
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> https://svn.apache.org/repos/asf/geronimo/components/txmanager
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
>
> https://svn.apache.org/repos/asf/geronimo/components/
> geronimo-schema-javaee_6
>
> https://svn.apache.org/repos/asf/geronimo/genesis/
> • Maven parents for geronimo-specs
>
> https://svn.apache.org/repos/asf/geronimo/javamail/
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
>
> https://svn.apache.org/repos/asf/geronimo/specs/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some
> official javax jars due to licensing concerns
>
> https://svn.apache.org/repos/asf/geronimo/xbean/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
>
> Osgi-locator too but guess this one can drop and belong to karaf or
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>
>
> I've created a google doc. Just ping me if you want to edit something and
> I'll share it.
>
> David, you mentioned JASPIC. I could not find that even. Is this inside
> the geronimo-server probably?
> Are there other gems which are not maintained as components but just
> inside geronimo?
>
> txs and LieGrue,
> strub
>
>
> > Am 09.03.2017 um 08:44 schrieb David Jencks :
> >
> > I go back and forth on whether to shut G down completely.  Perhaps it
> would be useful to inventory which parts are used by which other projects?
> Off the top of my head….
> >
> > Specs …. who uses G’s and who has their own?
> >
> > Components…. I think there are several users of the transaction manager,
> I don’t know about the connector framework, and I’m pretty sure no one uses
> my jaspic implementation.  The TM is stable but now that faster than
> spinning rust persistent memory is popular the logger could probably be
> rewritten to be much faster.
> >
> > xbean …. tomee I believe, anyone else?  Does activemq still use
> xbean-spring?  Knowing more about osgi now I might be able to gets
> xbean-blueprint to work:-)
> >
> > yoko is used by IBM, I doubt anyone else will get all excited about
> CORBA and start contributing.
> >
> > Any other bits being used?
> >
> > If we kept G around in a reduced state, how will we maintain enough
> interest to file the board reports?  Some days  I think I might have enough
> interest and some days not.
> >
> > If we did not shut down the whole project would we mark the removed bits
> (server primarily) as not being developed or move them to the attic?
> >
> > thanks
> > david jencks
> >
> >> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau 
> wrote:
> >>
> >> A valid point is activity related to G happens elsewhere, However
> elsewhere is not "tomee" which would make things simple to move but A, B, C
> so shutting down G is likely the easiest solution for G itself but also the
> worse for all its dependent projects - and ASF consistency since G is now
> seen as the owner of specs, xbean etcToday G is the result of
> communities and I don't see it as a bad thing even if not common @ASF. It
> allows new interactions with sometimes completely different area of
> knowledge which is actually great and can't happen elsewhere IMHO (the dead
> of G would mean fork per project probably).
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom :
> >> I’ve monitored G for several years since my departure.  For me, JEE is
> not my main area of focus and as such, I’ve invested little time in the
> project apart from reading the e-mail threads.  This is a community
> decision and posting the discussion to dev@ is the right venue.
> >>
> >> As an inactive member I don’t have a strong vote, but, my observation
> is that most of the community has moved on and there is little activity.
> If those that are still active want to keep going then God’s speed.
> >>
> >> Matt Hogstrom
> >> m...@hogstrom.org
> >> +1-919-656-0564
> >> PGP Key: 0x90ECB270
> >> Facebook  LinkedIn  Twitter
> >>
> >> "I’m smart enough to know how dumb I am."
> >> -  Hogstrom
> >>
> >>
> >>
> >>> On Mar 9, 2017, at 08:47, Jason Dillon  wrote:
> >>>
> >>> On

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

Romain and I went through the Geronimo SVN and made a list of which components 
are used by other projects.


Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/

https://svn.apache.org/repos/asf/geronimo/KEYS

https://svn.apache.org/repos/asf/geronimo/components/txmanager
• TomEE (txmgr+connector)
• Meecrowave (txmgr)
• Aries (txmgr)

https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6

https://svn.apache.org/repos/asf/geronimo/genesis/
• Maven parents for geronimo-specs

https://svn.apache.org/repos/asf/geronimo/javamail/
• TomEE as delivery
• Lot of standalone
• -> we can ask Hendrik pby

https://svn.apache.org/repos/asf/geronimo/specs/
• TomEE
• OpenWebBeans
• Meecrowave
• OpenJPA
• Johnzon
• BatchEE
• Karaf
• Aries
• Tons of external customer projects which don’t want to use some 
official javax jars due to licensing concerns

https://svn.apache.org/repos/asf/geronimo/xbean/
• TomEE
• OpenWebBeans
• Meecrowave
• Aries
• Karaf
• OpenJPA
• CXF (supported)

Osgi-locator too but guess this one can drop and belong to karaf or servicemix.
Q: well we need the osgi locator in our geronimo-specs, isn’t?


I've created a google doc. Just ping me if you want to edit something and I'll 
share it.

David, you mentioned JASPIC. I could not find that even. Is this inside the 
geronimo-server probably? 
Are there other gems which are not maintained as components but just inside 
geronimo?

txs and LieGrue,
strub


> Am 09.03.2017 um 08:44 schrieb David Jencks :
> 
> I go back and forth on whether to shut G down completely.  Perhaps it would 
> be useful to inventory which parts are used by which other projects? Off the 
> top of my head….
> 
> Specs …. who uses G’s and who has their own?
> 
> Components…. I think there are several users of the transaction manager, I 
> don’t know about the connector framework, and I’m pretty sure no one uses my 
> jaspic implementation.  The TM is stable but now that faster than spinning 
> rust persistent memory is popular the logger could probably be rewritten to 
> be much faster.
> 
> xbean …. tomee I believe, anyone else?  Does activemq still use xbean-spring? 
>  Knowing more about osgi now I might be able to gets xbean-blueprint to 
> work:-)
> 
> yoko is used by IBM, I doubt anyone else will get all excited about CORBA and 
> start contributing.
> 
> Any other bits being used?
> 
> If we kept G around in a reduced state, how will we maintain enough interest 
> to file the board reports?  Some days  I think I might have enough interest 
> and some days not.
> 
> If we did not shut down the whole project would we mark the removed bits 
> (server primarily) as not being developed or move them to the attic?
> 
> thanks
> david jencks
> 
>> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  
>> wrote:
>> 
>> A valid point is activity related to G happens elsewhere, However elsewhere 
>> is not "tomee" which would make things simple to move but A, B, C so 
>> shutting down G is likely the easiest solution for G itself but also the 
>> worse for all its dependent projects - and ASF consistency since G is now 
>> seen as the owner of specs, xbean etcToday G is the result of 
>> communities and I don't see it as a bad thing even if not common @ASF. It 
>> allows new interactions with sometimes completely different area of 
>> knowledge which is actually great and can't happen elsewhere IMHO (the dead 
>> of G would mean fork per project probably).
>> 
>> 
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> 
>> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom :
>> I’ve monitored G for several years since my departure.  For me, JEE is not 
>> my main area of focus and as such, I’ve invested little time in the project 
>> apart from reading the e-mail threads.  This is a community decision and 
>> posting the discussion to dev@ is the right venue.
>> 
>> As an inactive member I don’t have a strong vote, but, my observation is 
>> that most of the community has moved on and there is little activity.  If 
>> those that are still active want to keep going then God’s speed.
>> 
>> Matt Hogstrom
>> m...@hogstrom.org
>> +1-919-656-0564
>> PGP Key: 0x90ECB270
>> Facebook  LinkedIn  Twitter
>> 
>> "I’m smart enough to know how dumb I am."
>> -  Hogstrom
>> 
>> 
>> 
>>> On Mar 9, 2017, at 08:47, Jason Dillon  wrote:
>>> 
>>> On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de) wrote:
 Alan, I understand that you don't want to put much more energy into this 
 project. That is totally understandable and fine. 
 But while you are PMC chair you still cannot declare that the project is 
 dead as long as there are enough PMC members still active to keep the 
 project going. 
>>> 
>>> Mark, I agr

Re: Discuss: Move Geronimo to Attic

[David Jencks]

I go back and forth on whether to shut G down completely.  Perhaps it would be 
useful to inventory which parts are used by which other projects? Off the top 
of my head….

Specs …. who uses G’s and who has their own?

Components…. I think there are several users of the transaction manager, I 
don’t know about the connector framework, and I’m pretty sure no one uses my 
jaspic implementation.  The TM is stable but now that faster than spinning rust 
persistent memory is popular the logger could probably be rewritten to be much 
faster.

xbean …. tomee I believe, anyone else?  Does activemq still use xbean-spring?  
Knowing more about osgi now I might be able to gets xbean-blueprint to work:-)

yoko is used by IBM, I doubt anyone else will get all excited about CORBA and 
start contributing.

Any other bits being used?

If we kept G around in a reduced state, how will we maintain enough interest to 
file the board reports?  Some days  I think I might have enough interest and 
some days not.

If we did not shut down the whole project would we mark the removed bits 
(server primarily) as not being developed or move them to the attic?

thanks
david jencks

> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  wrote:
> 
> A valid point is activity related to G happens elsewhere, However elsewhere 
> is not "tomee" which would make things simple to move but A, B, C so shutting 
> down G is likely the easiest solution for G itself but also the worse for all 
> its dependent projects - and ASF consistency since G is now seen as the owner 
> of specs, xbean etcToday G is the result of communities and I don't see 
> it as a bad thing even if not common @ASF. It allows new interactions with 
> sometimes completely different area of knowledge which is actually great and 
> can't happen elsewhere IMHO (the dead of G would mean fork per project 
> probably).
> 
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | JavaEE Factory 
> 
> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom  >:
> I’ve monitored G for several years since my departure.  For me, JEE is not my 
> main area of focus and as such, I’ve invested little time in the project 
> apart from reading the e-mail threads.  This is a community decision and 
> posting the discussion to dev@ is the right venue.
> 
> As an inactive member I don’t have a strong vote, but, my observation is that 
> most of the community has moved on and there is little activity.  If those 
> that are still active want to keep going then God’s speed.
> 
> Matt Hogstrom
> m...@hogstrom.org 
> +1-919-656-0564
> PGP Key: 0x90ECB270
> Facebook   LinkedIn 
>   Twitter 
> 
> 
> "I’m smart enough to know how dumb I am."
> -  Hogstrom
> 
> 
> 
>> On Mar 9, 2017, at 08:47, Jason Dillon > > wrote:
>> 
>> On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de 
>> ) wrote:
>>> Alan, I understand that you don't want to put much more energy into this 
>>> project. That is totally understandable and fine. 
>>> But while you are PMC chair you still cannot declare that the project is 
>>> dead as long as there are enough PMC members still active to keep the 
>>> project going. 
>> 
>> Mark, I agree with Alan and Kevan, though put into my own words I think the 
>> project and community is no longer viable (and has not been for a while).  I 
>> do believe there are still useful aspects to the project, but I don’t think 
>> its enough to leave on its own.
>> 
>> We can certainly wait for more PMC members to chime in if they are still 
>> monitoring.  As Jeff recommended I’m including the private@ list for PMC 
>> folks that may not be paying as much attention to the dev@ list.
>> 
>>> Before we dump the project I suggest we start with an analysis of where we 
>>> are right now. 
>>> 
>>> What about starting look into 
>>> .) Who is still active and willing to continue Geronimo as a ee-commons 
>>> project? 
>> 
>> So far I’ve not really seen anyone over the past days of communication about 
>> this.  But we’ll see.
>> 
>> —jason
>> 
>> 
>> 
>>> .) Which project parts of the project are of some shared interest and might 
>>> be good to get some maintenance love and some realistic chance that this is 
>>> gonna happening? 
>> 
>> I can’t speak for the others, but I have zero interested in putting any love 
>> in to any of what is presently here.
>> 
>> I will defer to others to explain if they feel otherwise, though I do recall 
>> some chatter on private@ but will probably need those folks to re-post to 
>> dev@ to include

Re: Discuss: Move Geronimo to Attic

[Romain Manni-Bucau]

A valid point is activity related to G happens elsewhere, However elsewhere
is not "tomee" which would make things simple to move but A, B, C so
shutting down G is likely the easiest solution for G itself but also the
worse for all its dependent projects - and ASF consistency since G is now
seen as the owner of specs, xbean etcToday G is the result of
communities and I don't see it as a bad thing even if not common @ASF. It
allows new interactions with sometimes completely different area of
knowledge which is actually great and can't happen elsewhere IMHO (the dead
of G would mean fork per project probably).




Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-03-09 5:13 GMT+01:00 Matt Hogstrom :

> I’ve monitored G for several years since my departure.  For me, JEE is not
> my main area of focus and as such, I’ve invested little time in the project
> apart from reading the e-mail threads.  This is a community decision and
> posting the discussion to dev@ is the right venue.
>
> As an inactive member I don’t have a strong vote, but, my observation is
> that most of the community has moved on and there is little activity.  If
> those that are still active want to keep going then God’s speed.
>
> Matt Hogstrom
> m...@hogstrom.org
> +1-919-656-0564
> PGP Key: 0x90ECB270
> Facebook   LinkedIn
>   Twitter
> 
>
> "I’m smart enough to know how dumb I am."
> -  Hogstrom
>
>
>
> On Mar 9, 2017, at 08:47, Jason Dillon  wrote:
>
> On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de) wrote:
>
> Alan, I understand that you don't want to put much more energy into this
> project. That is totally understandable and fine.
> But while you are PMC chair you still cannot declare that the project is
> dead as long as there are enough PMC members still active to keep the
> project going.
>
>
> Mark, I agree with Alan and Kevan, though put into my own words I think
> the project and community is no longer viable (and has not been for a
> while).  I do believe there are still useful aspects to the project, but I
> don’t think its enough to leave on its own.
>
> We can certainly wait for more PMC members to chime in if they are still
> monitoring.  As Jeff recommended I’m including the private@ list for PMC
> folks that may not be paying as much attention to the dev@ list.
>
> Before we dump the project I suggest we start with an analysis of where we
> are right now.
>
> What about starting look into
> .) Who is still active and willing to continue Geronimo as a ee-commons
> project?
>
> So far I’ve not really seen anyone over the past days of communication
> about this.  But we’ll see.
>
> —jason
>
>
> .) Which project parts of the project are of some shared interest and
> might be good to get some maintenance love and some realistic chance that
> this is gonna happening?
>
> I can’t speak for the others, but I have zero interested in putting any
> love in to any of what is presently here.
>
> I will defer to others to explain if they feel otherwise, though I do
> recall some chatter on private@ but will probably need those folks to
> re-post to dev@ to include that discussion.
>
> —jason
>
>
>

Re: Discuss: Move Geronimo to Attic

[Matt Hogstrom]

I’ve monitored G for several years since my departure.  For me, JEE is not my 
main area of focus and as such, I’ve invested little time in the project apart 
from reading the e-mail threads.  This is a community decision and posting the 
discussion to dev@ is the right venue.

As an inactive member I don’t have a strong vote, but, my observation is that 
most of the community has moved on and there is little activity.  If those that 
are still active want to keep going then God’s speed.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 


"I’m smart enough to know how dumb I am."
-  Hogstrom



> On Mar 9, 2017, at 08:47, Jason Dillon  wrote:
> 
> On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de 
> ) wrote:
>> Alan, I understand that you don't want to put much more energy into this 
>> project. That is totally understandable and fine.
>> But while you are PMC chair you still cannot declare that the project is 
>> dead as long as there are enough PMC members still active to keep the 
>> project going.
> 
> Mark, I agree with Alan and Kevan, though put into my own words I think the 
> project and community is no longer viable (and has not been for a while).  I 
> do believe there are still useful aspects to the project, but I don’t think 
> its enough to leave on its own.
> 
> We can certainly wait for more PMC members to chime in if they are still 
> monitoring.  As Jeff recommended I’m including the private@ list for PMC 
> folks that may not be paying as much attention to the dev@ list.
> 
>> Before we dump the project I suggest we start with an analysis of where we 
>> are right now.
>> 
>> What about starting look into
>> .) Who is still active and willing to continue Geronimo as a ee-commons 
>> project?
> 
> So far I’ve not really seen anyone over the past days of communication about 
> this.  But we’ll see.
> 
> —jason
> 
> 
> 
>> .) Which project parts of the project are of some shared interest and might 
>> be good to get some maintenance love and some realistic chance that this is 
>> gonna happening?
> 
> I can’t speak for the others, but I have zero interested in putting any love 
> in to any of what is presently here.
> 
> I will defer to others to explain if they feel otherwise, though I do recall 
> some chatter on private@ but will probably need those folks to re-post to 
> dev@ to include that discussion.
> 
> —jason
> 



signature.asc
Description: Message signed with OpenPGP

Re: Discuss: Move Geronimo to Attic

[Jason Dillon]

On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de) wrote:
Alan, I understand that you don't want to put much more energy into this 
project. That is totally understandable and fine. 
But while you are PMC chair you still cannot declare that the project is dead 
as long as there are enough PMC members still active to keep the project going. 

Mark, I agree with Alan and Kevan, though put into my own words I think the 
project and community is no longer viable (and has not been for a while).  I do 
believe there are still useful aspects to the project, but I don’t think its 
enough to leave on its own.

We can certainly wait for more PMC members to chime in if they are still 
monitoring.  As Jeff recommended I’m including the private@ list for PMC folks 
that may not be paying as much attention to the dev@ list.

Before we dump the project I suggest we start with an analysis of where we are 
right now. 

What about starting look into 
.) Who is still active and willing to continue Geronimo as a ee-commons 
project? 
So far I’ve not really seen anyone over the past days of communication about 
this.  But we’ll see.

—jason



.) Which project parts of the project are of some shared interest and might be 
good to get some maintenance love and some realistic chance that this is gonna 
happening? 
I can’t speak for the others, but I have zero interested in putting any love in 
to any of what is presently here.

I will defer to others to explain if they feel otherwise, though I do recall 
some chatter on private@ but will probably need those folks to re-post to dev@ 
to include that discussion.

—jason

Re: Discuss: Move Geronimo to Attic

[Dave Horsey]

unsubscribe

On Wed, Mar 8, 2017 at 6:44 PM, Mark Struberg  wrote:

> Alan, I understand that you don't want to put much more energy into this
> project. That is totally understandable and fine.
> But while you are PMC chair you still cannot declare that the project is
> dead as long as there are enough PMC members still active to keep the
> project going.
>
>
> Before we dump the project I suggest we start with an analysis of where we
> are right now.
>
> What about starting look into
> .) Who is still active and willing to continue Geronimo as a ee-commons
> project?
> .) Which project parts of the project are of some shared interest and
> might be good to get some maintenance love and some realistic chance that
> this is gonna happening?
>
> txs and LieGrue,
> strub
>
>
> > Am 08.03.2017 um 16:38 schrieb Alan Cabrera :
> >
> > I agree and I even acknowledged that below, but what I feel Mark and you
> are not acknowledging is that the interest/activity is for a smaller subset
> of JEE.  Of that subset, even you list the OSS projects that are supporting
> the JEE bits that are still relevant.  They have active communities and are
> even likely to be using our implementation of our specs, but that is not
> reflective of the viability of Geronimo as an active JEE project at the ASF.
> >
> > Let us keep in mind that the raison d’être of Geronimo is the complete
> implementation of the JEE standard.  The JEE spec licensing that the
> project is bound to goes through excruciating lengths to make sure that the
> spec is implemented in toto and not piecemeal.  Given that the overwhelming
> bulk of the code is simply an inclusion of external OSS projects, when the
> existing active OSS projects are factored out there’s not a lot left.
> There’s no denying that much of what’s left is good technology.  It’s just
> not enough to jumpstart a new active OSS community.  And this is the crux
> of the matter, community.
> >
> > Does Geronimo still have good technology? Yes.
> >
> > When one factors out the existing OSS overlap, is it enough to jumpstart
> a new active community?  No.
> >
> > A few engineers applying patches once a year is not an active
> community.  To be sure the downstream OSS projects are appreciative.
> However, what’s the point?  The engineering activity here is really a proxy
> for other OSS projects and not indicative of the viability of Geronimo as
> an active ASF project.  Things get fixed and released, but in the end the
> wider community goes to the other OSS projects to consume those artifacts.
> >
> > Geronimo had a great run.  It made significant contributions to the
> industry.  However, the relevancy of the JEE spec has wained and the dearth
> of activity is concrete proof of that.
> >
> > With that said, this does not prevent a set of enterprising engineers
> with “can do” attitudes to pick over the bones that are in the Attic and
> create another application server.  But that effort, IMO, will need to be
> borne in the Incubator.
> >
> >
> > Regards,
> > Alan
> >
> >
> >> On Mar 8, 2017, at 1:34 AM, Romain Manni-Bucau 
> wrote:
> >>
> >> I share that vision (the one of Mark).
> >>
> >> The ee-commons part is really used and still active (even if in
> maintenance mode for several parts) and we need to ensure other projects
> can still rely on it (karaf, tomee, owb, meecrowave, openjpa, ... plus
> several open source ones).
> >>
> >> EE is also not dead, likely no more trendy since server side techno is
> no more a challenge but still a real need.
> >>
> >> Geronimo AppService not being really developped or maintained anymore I
> can see it being frozen (attic or not is a detail IMO) but other parts are
> still a very good fit for Geronimo community IMO.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-08 10:26 GMT+01:00 Mark Struberg :
> >> I see no lack of interest in Java EE to be honest. Of course
> Microservices are currently spilled high on the hype cycle, but that will
> quickly blow up imo.
> >> MS architecture is only very good for a certain kind of application.
> For most business apps the granularity is way too fine grain and the
> missing TX handling is often a showstopper (even if Managers don't see this
> yet).
> >>
> >> You are certainly right that there is a lack of interest in the *huge*
> big-iron app servers!
> >> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting
> for 85% of apps.
> >>
> >> I also do not have a problem with the missing TCK. Of course it would
> be better to have one. But the only real progress is currently in CDI and
> BVal and those TCKs are available under ALv2 even.
> >>
> >> The main problem imo is that the Geronimo server part is not actively
> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not
> that OSGi itself is bad, but it's not a good fit.
> >> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago,
> and

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

Alan, I understand that you don't want to put much more energy into this 
project. That is totally understandable and fine. 
But while you are PMC chair you still cannot declare that the project is dead 
as long as there are enough PMC members still active to keep the project going.


Before we dump the project I suggest we start with an analysis of where we are 
right now.

What about starting look into
.) Who is still active and willing to continue Geronimo as a ee-commons project?
.) Which project parts of the project are of some shared interest and might be 
good to get some maintenance love and some realistic chance that this is gonna 
happening?

txs and LieGrue,
strub


> Am 08.03.2017 um 16:38 schrieb Alan Cabrera :
> 
> I agree and I even acknowledged that below, but what I feel Mark and you are 
> not acknowledging is that the interest/activity is for a smaller subset of 
> JEE.  Of that subset, even you list the OSS projects that are supporting the 
> JEE bits that are still relevant.  They have active communities and are even 
> likely to be using our implementation of our specs, but that is not 
> reflective of the viability of Geronimo as an active JEE project at the ASF. 
> 
> Let us keep in mind that the raison d’être of Geronimo is the complete 
> implementation of the JEE standard.  The JEE spec licensing that the project 
> is bound to goes through excruciating lengths to make sure that the spec is 
> implemented in toto and not piecemeal.  Given that the overwhelming bulk of 
> the code is simply an inclusion of external OSS projects, when the existing 
> active OSS projects are factored out there’s not a lot left.  There’s no 
> denying that much of what’s left is good technology.  It’s just not enough to 
> jumpstart a new active OSS community.  And this is the crux of the matter, 
> community.
> 
> Does Geronimo still have good technology? Yes.
> 
> When one factors out the existing OSS overlap, is it enough to jumpstart a 
> new active community?  No.
> 
> A few engineers applying patches once a year is not an active community.  To 
> be sure the downstream OSS projects are appreciative.  However, what’s the 
> point?  The engineering activity here is really a proxy for other OSS 
> projects and not indicative of the viability of Geronimo as an active ASF 
> project.  Things get fixed and released, but in the end the wider community 
> goes to the other OSS projects to consume those artifacts.
> 
> Geronimo had a great run.  It made significant contributions to the industry. 
>  However, the relevancy of the JEE spec has wained and the dearth of activity 
> is concrete proof of that.
> 
> With that said, this does not prevent a set of enterprising engineers with 
> “can do” attitudes to pick over the bones that are in the Attic and create 
> another application server.  But that effort, IMO, will need to be borne in 
> the Incubator.
> 
> 
> Regards,
> Alan
> 
> 
>> On Mar 8, 2017, at 1:34 AM, Romain Manni-Bucau  wrote:
>> 
>> I share that vision (the one of Mark).
>> 
>> The ee-commons part is really used and still active (even if in maintenance 
>> mode for several parts) and we need to ensure other projects can still rely 
>> on it (karaf, tomee, owb, meecrowave, openjpa, ... plus several open source 
>> ones).
>> 
>> EE is also not dead, likely no more trendy since server side techno is no 
>> more a challenge but still a real need.
>> 
>> Geronimo AppService not being really developped or maintained anymore I can 
>> see it being frozen (attic or not is a detail IMO) but other parts are still 
>> a very good fit for Geronimo community IMO.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> 
>> 2017-03-08 10:26 GMT+01:00 Mark Struberg :
>> I see no lack of interest in Java EE to be honest. Of course Microservices 
>> are currently spilled high on the hype cycle, but that will quickly blow up 
>> imo.
>> MS architecture is only very good for a certain kind of application. For 
>> most business apps the granularity is way too fine grain and the missing TX 
>> handling is often a showstopper (even if Managers don't see this yet).
>> 
>> You are certainly right that there is a lack of interest in the *huge* 
>> big-iron app servers!
>> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting for 
>> 85% of apps.
>> 
>> I also do not have a problem with the missing TCK. Of course it would be 
>> better to have one. But the only real progress is currently in CDI and BVal 
>> and those TCKs are available under ALv2 even.
>> 
>> The main problem imo is that the Geronimo server part is not actively 
>> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not 
>> that OSGi itself is bad, but it's not a good fit.
>> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago, and 
>> all the people involved in this effort back then layed a rock solid 
>> fundament for all that came after that.

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

I agree and I even acknowledged that below, but what I feel Mark and you are 
not acknowledging is that the interest/activity is for a smaller subset of JEE. 
 Of that subset, even you list the OSS projects that are supporting the JEE 
bits that are still relevant.  They have active communities and are even likely 
to be using our implementation of our specs, but that is not reflective of the 
viability of Geronimo as an active JEE project at the ASF. 

Let us keep in mind that the raison d’être of Geronimo is the complete 
implementation of the JEE standard.  The JEE spec licensing that the project is 
bound to goes through excruciating lengths to make sure that the spec is 
implemented in toto and not piecemeal.  Given that the overwhelming bulk of the 
code is simply an inclusion of external OSS projects, when the existing active 
OSS projects are factored out there’s not a lot left.  There’s no denying that 
much of what’s left is good technology.  It’s just not enough to jumpstart a 
new active OSS community.  And this is the crux of the matter, community.

Does Geronimo still have good technology? Yes.

When one factors out the existing OSS overlap, is it enough to jumpstart a new 
active community?  No.

A few engineers applying patches once a year is not an active community.  To be 
sure the downstream OSS projects are appreciative.  However, what’s the point?  
The engineering activity here is really a proxy for other OSS projects and not 
indicative of the viability of Geronimo as an active ASF project.  Things get 
fixed and released, but in the end the wider community goes to the other OSS 
projects to consume those artifacts.

Geronimo had a great run.  It made significant contributions to the industry.  
However, the relevancy of the JEE spec has wained and the dearth of activity is 
concrete proof of that.

With that said, this does not prevent a set of enterprising engineers with “can 
do” attitudes to pick over the bones that are in the Attic and create another 
application server.  But that effort, IMO, will need to be borne in the 
Incubator.


Regards,
Alan


> On Mar 8, 2017, at 1:34 AM, Romain Manni-Bucau  wrote:
> 
> I share that vision (the one of Mark).
> 
> The ee-commons part is really used and still active (even if in maintenance 
> mode for several parts) and we need to ensure other projects can still rely 
> on it (karaf, tomee, owb, meecrowave, openjpa, ... plus several open source 
> ones).
> 
> EE is also not dead, likely no more trendy since server side techno is no 
> more a challenge but still a real need.
> 
> Geronimo AppService not being really developped or maintained anymore I can 
> see it being frozen (attic or not is a detail IMO) but other parts are still 
> a very good fit for Geronimo community IMO.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | JavaEE Factory 
> 
> 2017-03-08 10:26 GMT+01:00 Mark Struberg  >:
> I see no lack of interest in Java EE to be honest. Of course Microservices 
> are currently spilled high on the hype cycle, but that will quickly blow up 
> imo.
> MS architecture is only very good for a certain kind of application. For most 
> business apps the granularity is way too fine grain and the missing TX 
> handling is often a showstopper (even if Managers don't see this yet).
> 
> You are certainly right that there is a lack of interest in the *huge* 
> big-iron app servers!
> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting for 
> 85% of apps.
> 
> I also do not have a problem with the missing TCK. Of course it would be 
> better to have one. But the only real progress is currently in CDI and BVal 
> and those TCKs are available under ALv2 even.
> 
> The main problem imo is that the Geronimo server part is not actively 
> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not 
> that OSGi itself is bad, but it's not a good fit.
> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago, and 
> all the people involved in this effort back then layed a rock solid fundament 
> for all that came after that. But the architecture is still quite outdated 
> imo and it didn't get maintained for way too long.
> 
> 
> Otoh there is really a lot of good technology available inside the geronimo 
> project.
> 
> * geronimo-jta
> * javamail
> * xbean (including finder, scanner etc)
> * the specs
> and quite a few other nice parts and they still get committs and love.
> 
> I'd definitly keep them alive.
> 
> I'm aware that quite some older PMC members have historically been interested 
> in the Geronimo AppServer and not in maintaining the ee-commons part of the 
> geronimo project.
> But instead of du

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

Thanks Alan! Many thanks for all you've done!

I think we all agree that it is time to retire the Geronimo Server portions
of the project.

My apologies to Romain, Mark, David, and others, but:

I think the entire project should be retired. I confess that I am not
closely following the dev list (I scan it from time to time for a general
sense of what's happening).

I don't see sufficient community behind the remaining sub-projects. If the
Geronimo project didn't exist, I seriously doubt that there would be calls
to form a new Geronimo EE Commons project. In my view, Geronimo is a
convenient code repository for some people interested in releasing code.
Thus, I think the entire project should be moved to the Attic. If there are
parts of the project that should live on, then let them be incorporated
into projects that will provide them the community they deserve.

And now the olive branch...

If there is sufficient community, then that community should be able to
develop a new project description (
https://projects.apache.org/project.html?geronimo) and report to the board.
Note that this change of the project's charter, may require approval by the
Board. And I expect there may be some reluctance to create a new
Commons-style project at the ASF. If we're (you're) able to accomplish
this, then you have my full support.

kevan

On Wed, Mar 8, 2017 at 1:34 AM, Romain Manni-Bucau 
wrote:

> I share that vision (the one of Mark).
>
> The ee-commons part is really used and still active (even if in
> maintenance mode for several parts) and we need to ensure other projects
> can still rely on it (karaf, tomee, owb, meecrowave, openjpa, ... plus
> several open source ones).
>
> EE is also not dead, likely no more trendy since server side techno is no
> more a challenge but still a real need.
>
> Geronimo AppService not being really developped or maintained anymore I
> can see it being frozen (attic or not is a detail IMO) but other parts are
> still a very good fit for Geronimo community IMO.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | JavaEE Factory
> 
>
> 2017-03-08 10:26 GMT+01:00 Mark Struberg :
>
>> I see no lack of interest in Java EE to be honest. Of course
>> Microservices are currently spilled high on the hype cycle, but that will
>> quickly blow up imo.
>> MS architecture is only very good for a certain kind of application. For
>> most business apps the granularity is way too fine grain and the missing TX
>> handling is often a showstopper (even if Managers don't see this yet).
>>
>> You are certainly right that there is a lack of interest in the *huge*
>> big-iron app servers!
>> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting
>> for 85% of apps.
>>
>> I also do not have a problem with the missing TCK. Of course it would be
>> better to have one. But the only real progress is currently in CDI and BVal
>> and those TCKs are available under ALv2 even.
>>
>> The main problem imo is that the Geronimo server part is not actively
>> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not
>> that OSGi itself is bad, but it's not a good fit.
>> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago,
>> and all the people involved in this effort back then layed a rock solid
>> fundament for all that came after that. But the architecture is still quite
>> outdated imo and it didn't get maintained for way too long.
>>
>>
>> Otoh there is really a lot of good technology available inside the
>> geronimo project.
>>
>> * geronimo-jta
>> * javamail
>> * xbean (including finder, scanner etc)
>> * the specs
>> and quite a few other nice parts and they still get committs and love.
>>
>> I'd definitly keep them alive.
>>
>> I'm aware that quite some older PMC members have historically been
>> interested in the Geronimo AppServer and not in maintaining the ee-commons
>> part of the geronimo project.
>> But instead of dumping the whole project I'd say we just retire the
>> Geronimo AppServer and consolidate and focus on the single pieces. There
>> are potentially other things like Sirona-incubating which we could move
>> over as sub-projects even.
>>
>> Of course I perfectly understand if some of the older PMC members which
>> are not interested in the adopted roadmap want to retire.
>>
>> txs for all the hard work!
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 07.03.2017 um 22:44 schrieb Alan Cabrera :
>> >
>> > IMO, consultants and researchers are the earthworms of a vibrant OS
>> community that meets the standards sought after at the ASF.  I don’t see
>> how we’re going to attract them.  While the ideas posited on the mailing
>> lists are pretty interesting, I just don’t see any of the ideas attracting
>> 

Re: Discuss: Move Geronimo to Attic

[Romain Manni-Bucau]

I share that vision (the one of Mark).

The ee-commons part is really used and still active (even if in maintenance
mode for several parts) and we need to ensure other projects can still rely
on it (karaf, tomee, owb, meecrowave, openjpa, ... plus several open source
ones).

EE is also not dead, likely no more trendy since server side techno is no
more a challenge but still a real need.

Geronimo AppService not being really developped or maintained anymore I can
see it being frozen (attic or not is a detail IMO) but other parts are
still a very good fit for Geronimo community IMO.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-03-08 10:26 GMT+01:00 Mark Struberg :

> I see no lack of interest in Java EE to be honest. Of course Microservices
> are currently spilled high on the hype cycle, but that will quickly blow up
> imo.
> MS architecture is only very good for a certain kind of application. For
> most business apps the granularity is way too fine grain and the missing TX
> handling is often a showstopper (even if Managers don't see this yet).
>
> You are certainly right that there is a lack of interest in the *huge*
> big-iron app servers!
> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting for
> 85% of apps.
>
> I also do not have a problem with the missing TCK. Of course it would be
> better to have one. But the only real progress is currently in CDI and BVal
> and those TCKs are available under ALv2 even.
>
> The main problem imo is that the Geronimo server part is not actively
> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not
> that OSGi itself is bad, but it's not a good fit.
> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago,
> and all the people involved in this effort back then layed a rock solid
> fundament for all that came after that. But the architecture is still quite
> outdated imo and it didn't get maintained for way too long.
>
>
> Otoh there is really a lot of good technology available inside the
> geronimo project.
>
> * geronimo-jta
> * javamail
> * xbean (including finder, scanner etc)
> * the specs
> and quite a few other nice parts and they still get committs and love.
>
> I'd definitly keep them alive.
>
> I'm aware that quite some older PMC members have historically been
> interested in the Geronimo AppServer and not in maintaining the ee-commons
> part of the geronimo project.
> But instead of dumping the whole project I'd say we just retire the
> Geronimo AppServer and consolidate and focus on the single pieces. There
> are potentially other things like Sirona-incubating which we could move
> over as sub-projects even.
>
> Of course I perfectly understand if some of the older PMC members which
> are not interested in the adopted roadmap want to retire.
>
> txs for all the hard work!
>
> LieGrue,
> strub
>
>
> > Am 07.03.2017 um 22:44 schrieb Alan Cabrera :
> >
> > IMO, consultants and researchers are the earthworms of a vibrant OS
> community that meets the standards sought after at the ASF.  I don’t see
> how we’re going to attract them.  While the ideas posited on the mailing
> lists are pretty interesting, I just don’t see any of the ideas attracting
> a larger active community.  The reasons for this are
> >   • the lack of interest in JEE
> >   • inability to use a reasonably current JEE TCK
> >   • the size and age of the legacy code base
> >   • project members unable to commit time resources to mentor new
> members
> > When one reads about JEE not being “dead yet”, one is actually reading
> about a very small subset of the JEE spec.  To be sure, there are
> interesting problems still to be solved within certain silos of JEE.  I
> can’t think of anything that would apply to the entire pantheon of JEE
> bits; imo TomEE is already focused on the sweet spot of JEE bits that are
> still relevant.  One is hard pressed to think of any JEE sub-system in
> Geronimo that is not already separate project. The reality is that Geronimo
> was an amalgam of OSS projects and the industry has preserved those JEE
> bits that are still relevant.  The "value add", in no small part, of
> Geronimo was the comprehensive testing of the JEE pantheon in toto via the
> TCK.
> >
> > Given that we cannot use a reasonably current JEE TCK, the project is
> prevented from engaging in a role of JEE-commons of sorts.  Frankly, even
> if we were to get the current JEE TCK, nobody really cares anymore and, as
> I mentioned above, the interesting JEE bits are already being worked on
> elsewhere with their own specific TCKs.
> >
> > The size and age of the codebase makes it virtually impenetrable.  When
> one precludes spec commits, I think the last

Re: Discuss: Move Geronimo to Attic

[Mark Struberg]

I see no lack of interest in Java EE to be honest. Of course Microservices are 
currently spilled high on the hype cycle, but that will quickly blow up imo.
MS architecture is only very good for a certain kind of application. For most 
business apps the granularity is way too fine grain and the missing TX handling 
is often a showstopper (even if Managers don't see this yet).

You are certainly right that there is a lack of interest in the *huge* big-iron 
app servers!
So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting for 85% 
of apps.

I also do not have a problem with the missing TCK. Of course it would be better 
to have one. But the only real progress is currently in CDI and BVal and those 
TCKs are available under ALv2 even.

The main problem imo is that the Geronimo server part is not actively 
maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not 
that OSGi itself is bad, but it's not a good fit.
Don't get me wrong, the Geronimo AppServer was a big step 14 years ago, and all 
the people involved in this effort back then layed a rock solid fundament for 
all that came after that. But the architecture is still quite outdated imo and 
it didn't get maintained for way too long.


Otoh there is really a lot of good technology available inside the geronimo 
project. 

* geronimo-jta
* javamail
* xbean (including finder, scanner etc)
* the specs
and quite a few other nice parts and they still get committs and love.

I'd definitly keep them alive. 

I'm aware that quite some older PMC members have historically been interested 
in the Geronimo AppServer and not in maintaining the ee-commons part of the 
geronimo project. 
But instead of dumping the whole project I'd say we just retire the Geronimo 
AppServer and consolidate and focus on the single pieces. There are potentially 
other things like Sirona-incubating which we could move over as sub-projects 
even. 

Of course I perfectly understand if some of the older PMC members which are not 
interested in the adopted roadmap want to retire.

txs for all the hard work!

LieGrue,
strub


> Am 07.03.2017 um 22:44 schrieb Alan Cabrera :
> 
> IMO, consultants and researchers are the earthworms of a vibrant OS community 
> that meets the standards sought after at the ASF.  I don’t see how we’re 
> going to attract them.  While the ideas posited on the mailing lists are 
> pretty interesting, I just don’t see any of the ideas attracting a larger 
> active community.  The reasons for this are
>   • the lack of interest in JEE
>   • inability to use a reasonably current JEE TCK
>   • the size and age of the legacy code base 
>   • project members unable to commit time resources to mentor new members
> When one reads about JEE not being “dead yet”, one is actually reading about 
> a very small subset of the JEE spec.  To be sure, there are interesting 
> problems still to be solved within certain silos of JEE.  I can’t think of 
> anything that would apply to the entire pantheon of JEE bits; imo TomEE is 
> already focused on the sweet spot of JEE bits that are still relevant.  One 
> is hard pressed to think of any JEE sub-system in Geronimo that is not 
> already separate project. The reality is that Geronimo was an amalgam of OSS 
> projects and the industry has preserved those JEE bits that are still 
> relevant.  The "value add", in no small part, of Geronimo was the 
> comprehensive testing of the JEE pantheon in toto via the TCK.
> 
> Given that we cannot use a reasonably current JEE TCK, the project is 
> prevented from engaging in a role of JEE-commons of sorts.  Frankly, even if 
> we were to get the current JEE TCK, nobody really cares anymore and, as I 
> mentioned above, the interesting JEE bits are already being worked on 
> elsewhere with their own specific TCKs.
> 
> The size and age of the codebase makes it virtually impenetrable.  When one 
> precludes spec commits, I think the last real commit has been about a half a 
> decade ago; I wouldn’t be surprised if it was longer.  I personally have been 
> knee deep in it recently but find spelunking through it very daunting.  I’d 
> rather spend any free time I have in some greenfield endeavor.
> 
> I’m certain that other project members and passersby are of the same mind.  
> Since I have such little time to do greenfield coding, I have even less time 
> to mentor someone who is interested in tinkering with the code base.  I’ve no 
> doubt that others are of the same mind on this as well; witness the dearth of 
> replies to inquiries on this list.
> 
> There is a lot of blood, sweat, and tears in this project.  I, for one, am 
> honored to have been able to work with the world’s brightest coders on the 
> planet.  I have a lot of great memories, and hangovers, of our once vibrant 
> community and it’s very hard for me to start this thread.  I think we should 
> shutdown.  If anyone had a real interest in any kind of resurrection it would 
> have