geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Cabrera <l...@toolazydogs.com>
Subject Re: [DICSUSS] the future direction of the Apache Geronimo project
Date Wed, 18 Jan 2017 14:59:51 GMT

> On Jan 6, 2017, at 12:34 PM, David Jencks <david.a.jencks@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?

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



Mime
View raw message