geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: [DISCUSS] to plugin or not to plugin, that is the question
Date Sun, 02 Sep 2007 15:28:42 GMT
On 8/30/07, Joe Bohn <joe.bohn@earthlink.net> wrote:
> 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?

Well, the benefit of using OSGi is that one doesn't need to develop
and maintain (and define!) one's own plugin framework/engine. Over the
last 8 years, a lot of effort and experience has gone into the OSGi
specifications and it has proven to be a very good foundation even for
big projects (e.g., eclipse).

In my experience people tend to underestimate the amount of work it
takes to define, develop, and maintain a plugin framework. Choosing
OSGi is a good way to avoid that and given that there are three open
source implementation around atm there is little risk to end-up in
some kind of dead-end.

regards,

Karl

> > - 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
> >
>


-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message