geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: [DISCUSS] to plugin or not to plugin, that is the question
Date Thu, 30 Aug 2007 18:03:04 GMT
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]

View raw message