geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: [DISCUSS] to plugin or not to plugin, that is the question
Date Thu, 30 Aug 2007 19:39:54 GMT
On 8/30/07, 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 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.

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


View raw message