Hey Paul ... thanks for getting these discussions started. I had
intended to do the same (though perhaps not quite as thorough as you
have done).
Paul McMahan wrote:
We've been excited about and doing lots of interesting things with
plugins lately. From a big picture perspective I'm wondering where we
are headed. Some of my questions are:
- So do we all really agree that plugins are The Way and are we
prepared to reconsider how Geronimo is developed, built, and deployed
around that approach? Or should plugins remain as simply an alternate
mechanism for installing components and applications?
I think going this route is a must. We've been touting how flexible
Geronimo is and this makes it much more of a reality for our users.
Hopefully it will make it easier for us to manage all the moving parts
as well.
- What is the purpose of the framework assembly and how are the other
various assemblies built, installed, and configured?
We had a brief discussion of this on another thread where I questioned
if we wanted to keep "framework" around. It's better to centralize the
discussion here.
Framework was originally created with the idea that it would be the core
assembly and we could build up the other assemblies from it by
installing plugins. I think that's still the most architecturally pure
approach. (Note: we may want to try to remove more from framework so
that it doesn't include so many j2ee* configs). However in the other
thread, I was wondering if it makes sense to have a core framework that
really isn't of any use (to a user) without installing some additional
plugins. Perhaps the minimal assemblies would be better "roots" since
they have a purpose even without any additional plugins. I keep
waffling on this ... but at the moment I like the architectural purity
of having just one core assembly from which all others could be built.
- Can/should we build assemblies for TCK from plugins and if so how
would they be made available to end users? I heard some ideas about
using plugins as a component grouping mechanism that would allow users
to transform their server into a certified assembly by simply installing
their plugin of choice. That sounds promising and needs more thought.
Absolutely yes!!! I think we need to make the TCK changes regardless of
what we do with the main plugin strategy. However, I'm not clear on the
idea of a plugin itself being used to group other plugins. I was
thinking more along the lines of another construct which groups plugins
(we've referred to this as templates at various times). I suppose we
could build plugins that aggregated other plugins to accomplish this too
and that would negate the need for yet another type of item a user must
deal with.
- There is some work going on in GERONIMO-3330 to improve the
robustness and maintainability plugin catalogs. What other
infrastructure type requirements do we have for making plugin
repositories easy to use and maintain?
I think there's a lot of work to do here. IMO, we need to start
providing more capabilities for plugins to express compatibility with
other plugins (for example so that a plugin containing a web app could
express a dependency on a web container without having to call out jetty
or tomcat specifically if there are no hard dependencies). I also think
we need to make it so that plugins are not so tightly coupled to a
particular Geronimo version if not absolutely required. It would be
nice if we didn't have to re-release the JSP sample plugins for each new
Geronimo release.
- What usability improvements are needed in the plugin CLI and admin
console portlets?
I think there are definitely some .. but I won't try to itemize them now.
- Is there any place for OSGI in Geronimo's plugin strategy?
Good question ... I think there probably is but I'm a little concerned
about opening pandora's box. If OSGI makes it easier and quicker to get
to a more pluggable server and bring benefits for other integrators then
I think we should definitely consider it now. However, if it would
cause a significant delay in our delivery of a pluggable server I would
prefer we deliver the function first and swap out the engine later. Of
course there will be trade-offs here ... I guess the real question is
how substantial would a change to OSGI be at this time or later and is
that the direction that we want to move in?
- Java EE 6 (JSR 316) has a major theme of modularity and extensibility
in the application server[1]. How can we align our plugin strategy
with what's coming our way at a specification level?
Looks like more reading I need to catch up on :-)
Looking forward to your thoughts and follow on questions.
Best wishes,
Paul
[1] http://www.infoq.com/news/2007/07/jee6
