Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of karlpauls@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ZgwDc4SnZiGKNv/6ui7cgyQfdj4WJKlaX5Im0YFTLaSVgbQTjEfWdFtaEplXxFOpbelC+qRoCHq5xkHq0QVqUTeySYHMVOfAqOTXsPYMpl0aXdPiRRiZakvNabgRtBZD1sqpDF61CSFLudW5sdXqVeSKm9vRLOsd9RlgeZKYhFo=
Message-ID: <487a994c0709020828i6a425e46s47adad40f489975@mail.gmail.com>
Date: Sun, 2 Sep 2007 17:28:42 +0200
From: "Karl Pauls" <karlpauls@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: [DISCUSS] to plugin or not to plugin, that is the question
In-Reply-To: <46D70658.7030601@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <8C14EB65-8476-4BAC-B4DF-7C06EF1020BB@gmail.com>
	 <46D70658.7030601@earthlink.net>

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