geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [DISCUSS] to plugin or not to plugin, that is the question
Date Sun, 02 Sep 2007 15:46:34 GMT

On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote:

> On 8/30/07, Prasad Kashyap <> wrote:
>> 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.
> 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 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 :-)

we can do all this also :-)

How resilient is osgi in the face of wrong metadata in bundles?

Can you recommend a good reference for understanding how these parts  
of osgi work and just what osgi supports?  The spec is a bit thick to  
plow through all at once :-)

david jencks

> 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]
>> Cheers
>> Prasad
> -- 
> Karl Pauls

View raw message