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 66.249.92.170 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=Lh5hJg27IUmyxvxBwWlZ6nRCzm6XkIo/qE29QZPx/EyR/mxlIj85o9WmfKm0dbd8UHl1K9R2zL+4RZyEBcOQE4l12GUjysRNqQ+rcQ6NPKjbJclgNLZcsTFirBssmZ7tR+CcqjViHoQaSpuz7MXMYke2VA05MOqz5t9znVnj2zQ=
Message-ID: <487a994c0709020836v4292d2aekcb60acd3002fc72b@mail.gmail.com>
Date: Sun, 2 Sep 2007 17:36:19 +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: <c278ac970708301239r232ea0a7teac9c9e78c99573f@mail.gmail.com>
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>
	 <c278ac970708301239r232ea0a7teac9c9e78c99573f@mail.gmail.com>

On 8/30/07, Prasad Kashyap <goyathlay.geronimo@gmail.com> wrote:
> On 8/30/07, Paul McMahan <paulmcmahan@gmail.com> 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 am totally hooked on to the idea of a fully flexible, "build your
> own" server. To achieve this, the perfect stackable components are
> plugins.  So I'd like us to make everything other than the framework
> as plugins.
>
> >
> > -  What is the purpose of the framework assembly and how are the
> > other various assemblies built, installed, and configured?
>
> From an architectural standpoint, we shall always begin with a
> framework as our foundation. This will contain the least common
> denominator set of components that any conceivable assembly will
> contain. It will also contain the infrastructure to install other
> plugins. However, a framework by itself is of no business value to
> anybody. And since we are in the business of providing an application
> server, I think we should provide the 2 minimal assemblies as outputs
> to our end users. Those will be the ones we release.
>
> >
> > -  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.
>
> My thoughts on this was to assemble the CTS server by applying the
> relevant JEE5 plugins on the framework.Installing a plugin installs
> all it's dependencies too. So if a plugin with a certain profile is
> installed, it's dependencies will all be installed and thus we build a
> CTS server.
>
> >
> > -  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?
>
> To begin with, the ability to install and remove plugins is the most
> basic requirement.
>
> >
> > -  What usability improvements are needed in the plugin CLI and admin
> > console portlets?
>
> The plugins catalog must be viewable from the console. The plugin
> components should be listed with a checkbox next to it. Each plugin
> component can be further expanded/collapsed to reveal their runtime,
> deployer and admin plugins. Selecting a checkbox next to a component
> should install all it's 3 plugin pieces. However, the component can be
> expanded and it's individual plugin pieces can be selected too.
>
> Selecting a plugin's checkbox should also select all it's other
> dependencies' checkboxes.
>
> Plugin catalog
> o + jetty
> o  - openejb
>          o openejb-runtime
>          o openejb-deployer
>          o openejb-admin
>
> Imagine the o to be checkboxes.
>
>
> >
> > -  Is there any place for OSGI in Geronimo's plugin strategy?
>
> If all the plugins are developed and released independently, I wonder
> if dependencies on multiple versions can cause potential problems.
> Hmmm..  If somebody with a more thorough knowledge of how plugins
> currently handle versioning  can throw some light on this, it would be
> much appreciated.

This is an area explicitly targeted by OSGi. Bundles (i.e., modules)
in OSGi have dependencies on versioned packages (i.e., Java packages)
exported by other Bundles. It is possible to have several dependency
trees running side by side in the same VM as well as using version
ranges for dependencies (e.g., import javax.foo in version >= 1.3 and
<= 3.0).

The goal of OSGi allways has been to allow for plugins that are
developed and released independently. Not to mention that bundles can
be updated on the fly too :-)

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?
> >
> >
> > Looking forward to your thoughts and follow on questions.
> >
> >
> > Best wishes,
> > Paul
> >
> >
> > [1] http://www.infoq.com/news/2007/07/jee6
> >
>
> Cheers
> Prasad
>


-- 
Karl Pauls
karlpauls@gmail.com