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

[Sami Kallio <ph...@outlook.com>]

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 <da...@gmail.com>
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 <li...@toolazydogs.com>> wrote:


On Jan 6, 2017, at 12:34 PM, David Jencks <da...@gmail.com>> 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