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 17:25:02 GMT
On 9/2/07, Karl Pauls <karlpauls@gmail.com> wrote:
> On 9/2/07, David Jencks <david_jencks@yahoo.com> wrote:
> >
> > On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote:
> >
> > > 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 :-)
> >
> > we can do all this also :-)

On this note, can you maybe point me to some reference about the
current state of what you can do (it's been a while since I did look
at Geronimo's state in regard to plugins in anger).

regards,

Karl

> That's my point, the question is whether you want to continue to do it
> yourself when you can get the same for free :-)
>
> > How resilient is osgi in the face of wrong metadata in bundles?
>
> I guess I need a clarification on "resilient". In case you are asking
> what happens when a bundle has invalid meta-data then the answer is it
> will fail to either install (syntactic errors) or start (semantic
> errors). The framework itself will not be affected.
>
> > 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 :-)
>
> Well, a simple tutorial can be found here:
>
> http://felix.apache.org/site/apache-felix-osgi-tutorial.html
>
> Peter Kriens' blog is always a great resource in general and his
> "Snippets" specifically.
>
> The slides from Richard S. Hall from last years ApacheCon (who wrote
> the module part of the spec and is the Chair of Apache Felix) are a
> good start:
>
> http://felix.apache.org/site/presentations.data/osgi-apachecon-20060628.pdf
>
> Other then that, I really recommend looking into the module and
> framework section of the spec. It is (compared to many other specs)
> actually not too unreadable.
>
> We have a more advanced example in the making too (Rick's work again):
>
> http://felix.apache.org/site/apache-felix-application-demonstration.html
>
> and I already pointed to our embedding page in a different thread:
>
> http://felix.apache.org/site/launching-and-embedding-apache-felix.html
>
>
> Hope this helps.
>
> regards,
>
> Karl
>
> > thanks
> > 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] http://www.infoq.com/news/2007/07/jee6
> > >>>
> > >>
> > >> Cheers
> > >> Prasad
> > >>
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>


-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message