[DICSUSS] the future direction of the Apache Geronimo project

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[DICSUSS] the future direction of the Apache Geronimo project

Mark Struberg
Hi folks!

There have been some thoughts about resurrecting activity on the Geronimo AppServer.
So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
Of course if no fun is involved then a project is doomed as well.
But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.

So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE

* Mina as Socket Server
* Tomcat as native Servlet Container
* Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
* TomEE WebProfile (EE6 and EE7)
* TomEE Full (EE6 and EE7)
* Geronimo (EE6, OSGi)

+ httpd of course (but not Java)

To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.

What do others think?

LieGrue,
strub


Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

Romain Manni-Bucau
Same here, I wouldn't even try to find another home for "commons-ee" since this one is well known, works well and any other place wouldn't make more sense. On the server itself I fear there is not enough "resource" ATM to upgrade to EE 7 (even TomEE which is a bit more active has some issues to completely target it).

My question is then: what does it mean? Or said otherwise: what's the issue with current state? Is the target to rewamp the website (don't think we need to change much repos)?


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

2016-12-15 10:57 GMT+01:00 Mark Struberg <[hidden email]>:
Hi folks!

There have been some thoughts about resurrecting activity on the Geronimo AppServer.
So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
Of course if no fun is involved then a project is doomed as well.
But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.

So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE

* Mina as Socket Server
* Tomcat as native Servlet Container
* Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
* TomEE WebProfile (EE6 and EE7)
* TomEE Full (EE6 and EE7)
* Geronimo (EE6, OSGi)

+ httpd of course (but not Java)

To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.

What do others think?

LieGrue,
strub



Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

David Jencks
In reply to this post by Mark Struberg
I agree.  Which components specifically are you thinking of?

david jencks

> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>
> Hi folks!
>
> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
> Of course if no fun is involved then a project is doomed as well.
> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>
> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>
> * Mina as Socket Server
> * Tomcat as native Servlet Container
> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
> * TomEE WebProfile (EE6 and EE7)
> * TomEE Full (EE6 and EE7)
> * Geronimo (EE6, OSGi)
>
> + httpd of course (but not Java)
>
> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>
> What do others think?
>
> LieGrue,
> strub
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

Mark Struberg
Parts which I found to be actively maintained and very useful

* specs
* xbean
* javamail
* transactionmanager
* flava (needed for specs)

I'm sure there are others which are not on my radar,...

LieGrue,
strub

> Am 15.12.2016 um 21:41 schrieb David Jencks <[hidden email]>:
>
> I agree.  Which components specifically are you thinking of?
>
> david jencks
>
>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>>
>> Hi folks!
>>
>> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
>> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
>> Of course if no fun is involved then a project is doomed as well.
>> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>>
>> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>>
>> * Mina as Socket Server
>> * Tomcat as native Servlet Container
>> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
>> * TomEE WebProfile (EE6 and EE7)
>> * TomEE Full (EE6 and EE7)
>> * Geronimo (EE6, OSGi)
>>
>> + httpd of course (but not Java)
>>
>> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>>
>> What do others think?
>>
>> LieGrue,
>> strub
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

eduardogt
It would be desirable to have an official new version, with full
compatibility with new Java JDK's (this helps promoting people on using
it), also updating official web page, and Eclipse Plugin.

I had to put the front-end of a project into a TomEE due web-responsive
JSF requirements, but still using Geronimo as the core (back-end), by
using microservices (Restlet/Jackson).  Geronimo really rocks, but I
think it is time to get a renew version compatible with new key libraries.

I really like Geronimo AppServer and hope it continue growing.  In my
case, I started using geronimo because it was really easy for me
learning it with the Eclipse Tools available at that time (IBM OSGi
Tools).  Right now I have to use WAS or Liberty Tools with Eclipse Luna.

My wish list for Geronimo:
- Updated OSGi framework
- Been able to install Camel
- Updated MyFaces compatibility and fix some non-critical bugs
- Compatibility with new JDK
- Updated Eclipse Plugin
-  Try to deliver a new release once a year

hope next year could join you guys in making some of this happen.



On 12/16/2016 12:54 PM, Mark Struberg wrote:

> Parts which I found to be actively maintained and very useful
>
> * specs
> * xbean
> * javamail
> * transactionmanager
> * flava (needed for specs)
>
> I'm sure there are others which are not on my radar,...
>
> LieGrue,
> strub
>
>> Am 15.12.2016 um 21:41 schrieb David Jencks <[hidden email]>:
>>
>> I agree.  Which components specifically are you thinking of?
>>
>> david jencks
>>
>>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>>>
>>> Hi folks!
>>>
>>> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
>>> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
>>> Of course if no fun is involved then a project is doomed as well.
>>> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>>>
>>> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>>>
>>> * Mina as Socket Server
>>> * Tomcat as native Servlet Container
>>> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
>>> * TomEE WebProfile (EE6 and EE7)
>>> * TomEE Full (EE6 and EE7)
>>> * Geronimo (EE6, OSGi)
>>>
>>> + httpd of course (but not Java)
>>>
>>> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>>>
>>> What do others think?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

kevan
Administrator
Thanks Eduardo!

If there are people interested in working on updating the Geronimo server, I'm sure the community would happily support these efforts. So, if you or anyone else are interested, please speak up!

Also, if there are people interested in supporting the currently released version(s) of the Geronimo, server, I think the community would be supportive of these efforts, also.

Unfortunately, there has not been much interest from the current community for either of these efforts. I confess that I'm not planning on providing support for the existing codebase or working on a new version of the Geronimo server. 

Mark,
Your plan seems reasonable to me. Unless we plan on supporting the current version of the server (fixing bugs and security exposures) and/or developing a new updated server, I think we must move the server subproject to the Attic.

I do not plan on participating in the community for either commons or server development. Once the future plans for the Geronimo Server have been finalized, I will plan on resigning from the PMC.

kevan

On Tue, Dec 20, 2016 at 7:21 AM, Eduardo Garcia <[hidden email]> wrote:
It would be desirable to have an official new version, with full
compatibility with new Java JDK's (this helps promoting people on using
it), also updating official web page, and Eclipse Plugin.

I had to put the front-end of a project into a TomEE due web-responsive
JSF requirements, but still using Geronimo as the core (back-end), by
using microservices (Restlet/Jackson).  Geronimo really rocks, but I
think it is time to get a renew version compatible with new key libraries.

I really like Geronimo AppServer and hope it continue growing.  In my
case, I started using geronimo because it was really easy for me
learning it with the Eclipse Tools available at that time (IBM OSGi
Tools).  Right now I have to use WAS or Liberty Tools with Eclipse Luna.

My wish list for Geronimo:
- Updated OSGi framework
- Been able to install Camel
- Updated MyFaces compatibility and fix some non-critical bugs
- Compatibility with new JDK
- Updated Eclipse Plugin
-  Try to deliver a new release once a year

hope next year could join you guys in making some of this happen.



On 12/16/2016 12:54 PM, Mark Struberg wrote:
> Parts which I found to be actively maintained and very useful
>
> * specs
> * xbean
> * javamail
> * transactionmanager
> * flava (needed for specs)
>
> I'm sure there are others which are not on my radar,...
>
> LieGrue,
> strub
>
>> Am 15.12.2016 um 21:41 schrieb David Jencks <[hidden email]>:
>>
>> I agree.  Which components specifically are you thinking of?
>>
>> david jencks
>>
>>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>>>
>>> Hi folks!
>>>
>>> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
>>> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
>>> Of course if no fun is involved then a project is doomed as well.
>>> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>>>
>>> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>>>
>>> * Mina as Socket Server
>>> * Tomcat as native Servlet Container
>>> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
>>> * TomEE WebProfile (EE6 and EE7)
>>> * TomEE Full (EE6 and EE7)
>>> * Geronimo (EE6, OSGi)
>>>
>>> + httpd of course (but not Java)
>>>
>>> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>>>
>>> What do others think?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

eduardogt

I think Geronimo worth a chance to be updated.  There are not that much OSGi enable application servers out there, and this one is pretty stable.  I think the first steps toward a new version would include a rethink of its architecture, considering how the projects used by Geronimo are evolving right now (Karaf, Aries, Commons, etc.) and current market trends, including new interesting features (cloud enabled micro-version of Geronimo perhaps, OSGi annotations, small footprint, etc).  One of the things people are concern in open source is short live of projects.  Geronimo has been there for a while, so there is another good reason to keep pumping this project.

It would be appreciated any docs helping the process of updating Geronimo, besides at this point, it could be needed a "from zero" start due long time without an official release, in order to start a proof of concept.



On 12/27/2016 04:17 PM, Kevan Miller wrote:
Thanks Eduardo!

If there are people interested in working on updating the Geronimo server, I'm sure the community would happily support these efforts. So, if you or anyone else are interested, please speak up!

Also, if there are people interested in supporting the currently released version(s) of the Geronimo, server, I think the community would be supportive of these efforts, also.

Unfortunately, there has not been much interest from the current community for either of these efforts. I confess that I'm not planning on providing support for the existing codebase or working on a new version of the Geronimo server. 

Mark,
Your plan seems reasonable to me. Unless we plan on supporting the current version of the server (fixing bugs and security exposures) and/or developing a new updated server, I think we must move the server subproject to the Attic.

I do not plan on participating in the community for either commons or server development. Once the future plans for the Geronimo Server have been finalized, I will plan on resigning from the PMC.

kevan

On Tue, Dec 20, 2016 at 7:21 AM, Eduardo Garcia <[hidden email]> wrote:
It would be desirable to have an official new version, with full
compatibility with new Java JDK's (this helps promoting people on using
it), also updating official web page, and Eclipse Plugin.

I had to put the front-end of a project into a TomEE due web-responsive
JSF requirements, but still using Geronimo as the core (back-end), by
using microservices (Restlet/Jackson).  Geronimo really rocks, but I
think it is time to get a renew version compatible with new key libraries.

I really like Geronimo AppServer and hope it continue growing.  In my
case, I started using geronimo because it was really easy for me
learning it with the Eclipse Tools available at that time (IBM OSGi
Tools).  Right now I have to use WAS or Liberty Tools with Eclipse Luna.

My wish list for Geronimo:
- Updated OSGi framework
- Been able to install Camel
- Updated MyFaces compatibility and fix some non-critical bugs
- Compatibility with new JDK
- Updated Eclipse Plugin
-  Try to deliver a new release once a year

hope next year could join you guys in making some of this happen.



On 12/16/2016 12:54 PM, Mark Struberg wrote:
> Parts which I found to be actively maintained and very useful
>
> * specs
> * xbean
> * javamail
> * transactionmanager
> * flava (needed for specs)
>
> I'm sure there are others which are not on my radar,...
>
> LieGrue,
> strub
>
>> Am 15.12.2016 um 21:41 schrieb David Jencks <[hidden email]>:
>>
>> I agree.  Which components specifically are you thinking of?
>>
>> david jencks
>>
>>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>>>
>>> Hi folks!
>>>
>>> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
>>> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
>>> Of course if no fun is involved then a project is doomed as well.
>>> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>>>
>>> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>>>
>>> * Mina as Socket Server
>>> * Tomcat as native Servlet Container
>>> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
>>> * TomEE WebProfile (EE6 and EE7)
>>> * TomEE Full (EE6 and EE7)
>>> * Geronimo (EE6, OSGi)
>>>
>>> + httpd of course (but not Java)
>>>
>>> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>>>
>>> What do others think?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>



Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

David Jencks-3
I’m not sure how much interest there would be in an osgi based javaee app server.  I expect osgi-aware projects would likely try to avoid most of the javaee cruft and go directly to better-integrated-with osgi stuff such as that being demonstrated in enroute and non-osgi aware projects would be likely to want something lighter weight such as tomee.

However….. should anyone wish to revive Geronimo… my advice would be:

- drop the geronimo framework.
- (possibly) write a config admin management agent that reads something like current geronimo configuration files and turns them into osgi configurations.  I think some way of representing data trees in an osgi configuration is essential.  I tend to prefer encoding the path to a data element in the key, so values are all simple, but most osgi people seem to prefer encoding the data tree in json or yaml with simple keys and complex values.  I think osgi R7 is likely to support the latter approach.
- Rewrite all the integration code (most of geronimo) to use up-to-date (R7, actually) declarative services.  As part of this, make actual bundles with only interfaces exported and all the implementation   hidden.
- Run it in plain Karaf.

This would involve an extended period in which little to nothing worked.

When I tried to osgi-ify geronimo, I was hampered by
- trying to do it pretty much by myself — it is too large a job for one person IMO.
- trying to keep a working product most of the time — starting over with a DS based component model is definitely the way to proceed
- the DS implementation was too buggy, I didn’t know enough about DS, and the DS spec was too primitive — all of these have been fixed, although I don’t imagine I would  participate much in a revival much beyond giving advice.

good luck!

david jencks

On Jan 6, 2017, at 11:49 AM, Eduardo Garcia <[hidden email]> wrote:

I think Geronimo worth a chance to be updated.  There are not that much OSGi enable application servers out there, and this one is pretty stable.  I think the first steps toward a new version would include a rethink of its architecture, considering how the projects used by Geronimo are evolving right now (Karaf, Aries, Commons, etc.) and current market trends, including new interesting features (cloud enabled micro-version of Geronimo perhaps, OSGi annotations, small footprint, etc).  One of the things people are concern in open source is short live of projects.  Geronimo has been there for a while, so there is another good reason to keep pumping this project.

It would be appreciated any docs helping the process of updating Geronimo, besides at this point, it could be needed a "from zero" start due long time without an official release, in order to start a proof of concept.



On 12/27/2016 04:17 PM, Kevan Miller wrote:
Thanks Eduardo!

If there are people interested in working on updating the Geronimo server, I'm sure the community would happily support these efforts. So, if you or anyone else are interested, please speak up!

Also, if there are people interested in supporting the currently released version(s) of the Geronimo, server, I think the community would be supportive of these efforts, also.

Unfortunately, there has not been much interest from the current community for either of these efforts. I confess that I'm not planning on providing support for the existing codebase or working on a new version of the Geronimo server. 

Mark,
Your plan seems reasonable to me. Unless we plan on supporting the current version of the server (fixing bugs and security exposures) and/or developing a new updated server, I think we must move the server subproject to the Attic.

I do not plan on participating in the community for either commons or server development. Once the future plans for the Geronimo Server have been finalized, I will plan on resigning from the PMC.

kevan

On Tue, Dec 20, 2016 at 7:21 AM, Eduardo Garcia <[hidden email]> wrote:
It would be desirable to have an official new version, with full
compatibility with new Java JDK's (this helps promoting people on using
it), also updating official web page, and Eclipse Plugin.

I had to put the front-end of a project into a TomEE due web-responsive
JSF requirements, but still using Geronimo as the core (back-end), by
using microservices (Restlet/Jackson).  Geronimo really rocks, but I
think it is time to get a renew version compatible with new key libraries.

I really like Geronimo AppServer and hope it continue growing.  In my
case, I started using geronimo because it was really easy for me
learning it with the Eclipse Tools available at that time (IBM OSGi
Tools).  Right now I have to use WAS or Liberty Tools with Eclipse Luna.

My wish list for Geronimo:
- Updated OSGi framework
- Been able to install Camel
- Updated MyFaces compatibility and fix some non-critical bugs
- Compatibility with new JDK
- Updated Eclipse Plugin
-  Try to deliver a new release once a year

hope next year could join you guys in making some of this happen.



On 12/16/2016 12:54 PM, Mark Struberg wrote:
> Parts which I found to be actively maintained and very useful
>
> * specs
> * xbean
> * javamail
> * transactionmanager
> * flava (needed for specs)
>
> I'm sure there are others which are not on my radar,...
>
> LieGrue,
> strub
>
>> Am 15.12.2016 um 21:41 schrieb David Jencks <[hidden email]>:
>>
>> I agree.  Which components specifically are you thinking of?
>>
>> david jencks
>>
>>> On Dec 15, 2016, at 1:57 AM, Mark Struberg <[hidden email]> wrote:
>>>
>>> Hi folks!
>>>
>>> There have been some thoughts about resurrecting activity on the Geronimo AppServer.
>>> So imo the first step is to find a spot which makes sense. Software doesn't get built just for fun.
>>> Of course if no fun is involved then a project is doomed as well.
>>> But otoh if it doesn't get used then the quality suffers a lot and the fun is gone as well.
>>>
>>> So we have a few Java App Servers (just at the ASF), sorted from fastest/smallest to full EE
>>>
>>> * Mina as Socket Server
>>> * Tomcat as native Servlet Container
>>> * Brand new: OpenWebBeans Meecrowave as Microprofile server (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar btw ;)
>>> * TomEE WebProfile (EE6 and EE7)
>>> * TomEE Full (EE6 and EE7)
>>> * Geronimo (EE6, OSGi)
>>>
>>> + httpd of course (but not Java)
>>>
>>> To be honest I've not seen the Geronimo AppServer in production since quite a few years. Otoh the components maintained over here are of great quality and also an important puzzle part of many other projects. In my eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
>>>
>>> What do others think?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>




Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

Alan Cabrera-2

> On Jan 6, 2017, at 12:34 PM, David Jencks <[hidden email]> wrote:
>
> I’m not sure how much interest there would be in an osgi based javaee app server.  I expect osgi-aware projects would likely try to avoid most of the javaee cruft and go directly to better-integrated-with osgi stuff such as that being demonstrated in enroute and non-osgi aware projects would be likely to want something lighter weight such as tomee.
>
> However….. should anyone wish to revive Geronimo… my advice would be:
>
> - drop the geronimo framework.
> - (possibly) write a config admin management agent that reads something like current geronimo configuration files and turns them into osgi configurations.  I think some way of representing data trees in an osgi configuration is essential.  I tend to prefer encoding the path to a data element in the key, so values are all simple, but most osgi people seem to prefer encoding the data tree in json or yaml with simple keys and complex values.  I think osgi R7 is likely to support the latter approach.
> - Rewrite all the integration code (most of geronimo) to use up-to-date (R7, actually) declarative services.  As part of this, make actual bundles with only interfaces exported and all the implementation   hidden.
> - Run it in plain Karaf.
>
> This would involve an extended period in which little to nothing worked.
>
> When I tried to osgi-ify geronimo, I was hampered by
> - trying to do it pretty much by myself — it is too large a job for one person IMO.
> - trying to keep a working product most of the time — starting over with a DS based component model is definitely the way to proceed
> - the DS implementation was too buggy, I didn’t know enough about DS, and the DS spec was too primitive — all of these have been fixed, although I don’t imagine I would  participate much in a revival much beyond giving advice.

Is there a simple place to start where we can start doing tight iterations?  What’s the simplest JEE bit that we can start with?  Maybe we start with Yoko?

re: configuration - configuration has a lot of definitions, though there may be a standard definition in this context and I have forgotten it.  Are you referring to how one can assemble the various bits of JEE onto an OSGi runtime?

I think we should also re-boot the build framework as well.  The current one seems to be quite complicated and impenetrable.  I am now a Gradle fan-boi.


Regards,
Alan


Reply | Threaded
Open this post in threaded view
|

Re: [DICSUSS] the future direction of the Apache Geronimo project

David Jencks-3

On Jan 18, 2017, at 6:59 AM, Alan Cabrera <[hidden email]> wrote:


On Jan 6, 2017, at 12:34 PM, David Jencks <[hidden email]> wrote:

I’m not sure how much interest there would be in an osgi based javaee app server.  I expect osgi-aware projects would likely try to avoid most of the javaee cruft and go directly to better-integrated-with osgi stuff such as that being demonstrated in enroute and non-osgi aware projects would be likely to want something lighter weight such as tomee.

However….. should anyone wish to revive Geronimo… my advice would be:

- drop the geronimo framework.
- (possibly) write a config admin management agent that reads something like current geronimo configuration files and turns them into osgi configurations.  I think some way of representing data trees in an osgi configuration is essential.  I tend to prefer encoding the path to a data element in the key, so values are all simple, but most osgi people seem to prefer encoding the data tree in json or yaml with simple keys and complex values.  I think osgi R7 is likely to support the latter approach.
- Rewrite all the integration code (most of geronimo) to use up-to-date (R7, actually) declarative services.  As part of this, make actual bundles with only interfaces exported and all the implementation   hidden.
- Run it in plain Karaf.

This would involve an extended period in which little to nothing worked.

When I tried to osgi-ify geronimo, I was hampered by
- trying to do it pretty much by myself — it is too large a job for one person IMO.
- trying to keep a working product most of the time — starting over with a DS based component model is definitely the way to proceed
- the DS implementation was too buggy, I didn’t know enough about DS, and the DS spec was too primitive — all of these have been fixed, although I don’t imagine I would  participate much in a revival much beyond giving advice.

Is there a simple place to start where we can start doing tight iterations?  What’s the simplest JEE bit that we can start with?  Maybe we start with Yoko?

CORBA isn’t really useful without a lot of other stuff in place, if then :-(.  I’d suggest servlet support.

re: configuration - configuration has a lot of definitions, though there may be a standard definition in this context and I have forgotten it.  Are you referring to how one can assemble the various bits of JEE onto an OSGi runtime?

I was thinking of the information formerly in geronimo.xml.  Perhaps nowadays using YAMLwould be more friendly.  This information needs to  be converted somehow to OSGI configurations.
The question of which  bundles to include/start seems like it could be answered using karaf features.

I think we should also re-boot the build framework as well.  The current one seems to be quite complicated and impenetrable.  I am now a Gradle fan-boi.

since this would be osgi, bnd-gradle/bndtools.

david jencks


Regards,
Alan

Reply | Threaded
Open this post in threaded view
|

VS: [DICSUSS] the future direction of the Apache Geronimo project

Sami Kallio

Hi!


I have never been part of any open source project, nor have I used Geronimo for anything. Actually, even being 37 years old, I've been in software development career just little over a year! So I'm novice both in software development and in Geronimo.


However, Geronimo seems to me a very intriguing technology. I'm a full-stack Java developer working with Atlassian JIRA and Confluence servers, and I find application servers very interesting. As Geronimo is a Java EE application server, it combines the two things I've found appealing.


Geronimo seems to be indeed for extra hands, or more. I might not have very much to offer at this point, but being part of Geronimo development might be an important learning opportunity for me.


What I'm trying to say is, as this is a discussion about future direction of Geronimo, maybe about the future of the project itself, that I would like to be part of that future.


-Sami


Lähettäjä: David Jencks <[hidden email]>
Lähetetty: 18. tammikuuta 2017 19:53
Vastaanottaja: Geronimo Dev List (JIRA)
Aihe: Re: [DICSUSS] the future direction of the Apache Geronimo project
 

On Jan 18, 2017, at 6:59 AM, Alan Cabrera <[hidden email]> wrote:


On Jan 6, 2017, at 12:34 PM, David Jencks <[hidden email]> wrote:

I’m not sure how much interest there would be in an osgi based javaee app server.  I expect osgi-aware projects would likely try to avoid most of the javaee cruft and go directly to better-integrated-with osgi stuff such as that being demonstrated in enroute and non-osgi aware projects would be likely to want something lighter weight such as tomee.

However….. should anyone wish to revive Geronimo… my advice would be:

- drop the geronimo framework.
- (possibly) write a config admin management agent that reads something like current geronimo configuration files and turns them into osgi configurations.  I think some way of representing data trees in an osgi configuration is essential.  I tend to prefer encoding the path to a data element in the key, so values are all simple, but most osgi people seem to prefer encoding the data tree in json or yaml with simple keys and complex values.  I think osgi R7 is likely to support the latter approach.
- Rewrite all the integration code (most of geronimo) to use up-to-date (R7, actually) declarative services.  As part of this, make actual bundles with only interfaces exported and all the implementation   hidden.
- Run it in plain Karaf.

This would involve an extended period in which little to nothing worked.

When I tried to osgi-ify geronimo, I was hampered by
- trying to do it pretty much by myself — it is too large a job for one person IMO.
- trying to keep a working product most of the time — starting over with a DS based component model is definitely the way to proceed
- the DS implementation was too buggy, I didn’t know enough about DS, and the DS spec was too primitive — all of these have been fixed, although I don’t imagine I would  participate much in a revival much beyond giving advice.

Is there a simple place to start where we can start doing tight iterations?  What’s the simplest JEE bit that we can start with?  Maybe we start with Yoko?

CORBA isn’t really useful without a lot of other stuff in place, if then :-(.  I’d suggest servlet support.

re: configuration - configuration has a lot of definitions, though there may be a standard definition in this context and I have forgotten it.  Are you referring to how one can assemble the various bits of JEE onto an OSGi runtime?

I was thinking of the information formerly in geronimo.xml.  Perhaps nowadays using YAMLwould be more friendly.  This information needs to  be converted somehow to OSGI configurations.
The question of which  bundles to include/start seems like it could be answered using karaf features.

I think we should also re-boot the build framework as well.  The current one seems to be quite complicated and impenetrable.  I am now a Gradle fan-boi.

since this would be osgi, bnd-gradle/bndtools.

david jencks


Regards,
Alan