You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Paul McMahan <pa...@gmail.com> on 2007/08/30 18:15:50 UTC
[DISCUSS] to plugin or not to plugin, that is the question
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?
- What is the purpose of the framework assembly and how are the
other various assemblies built, installed, and configured?
- 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.
- 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?
- What usability improvements are needed in the plugin CLI and admin
console portlets?
- Is there any place for OSGI in Geronimo's plugin strategy?
- 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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Karl Pauls <ka...@gmail.com>.
On 8/30/07, Joe Bohn <jo...@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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Joe Bohn <jo...@earthlink.net>.
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?
>
> - 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
>
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Karl Pauls <ka...@gmail.com>.
On 9/2/07, Karl Pauls <ka...@gmail.com> wrote:
> On 9/2/07, David Jencks <da...@yahoo.com> wrote:
> >
> > On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote:
> >
> > > On 8/30/07, Prasad Kashyap <go...@gmail.com> wrote:
> > >> On 8/30/07, Paul McMahan <pa...@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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Karl Pauls <ka...@gmail.com>.
On 9/2/07, David Jencks <da...@yahoo.com> wrote:
>
> On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote:
>
> > On 8/30/07, Prasad Kashyap <go...@gmail.com> wrote:
> >> On 8/30/07, Paul McMahan <pa...@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 :-)
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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by David Jencks <da...@yahoo.com>.
On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote:
> On 8/30/07, Prasad Kashyap <go...@gmail.com> wrote:
>> On 8/30/07, Paul McMahan <pa...@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 :-)
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 :-)
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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Karl Pauls <ka...@gmail.com>.
On 8/30/07, Prasad Kashyap <go...@gmail.com> wrote:
> On 8/30/07, Paul McMahan <pa...@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
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Paul McMahan <pa...@gmail.com>.
On Aug 30, 2007, at 3:39 PM, Prasad Kashyap wrote:
>>
>> - 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.
My experience so far has been that plugins only work on the version
of Geronimo that they are exported from (or the version of car
plugin), mainly due to the fact that their configuration data is
stored in a serialized gbean info java object. When an API changes
in the server it usually makes previously exported plugins
incompatible. This has a lot of ramifications on release
management. Using XML as the serialization format for configuration
data could help, I forget where that discussion left off.
Best wishes,
Paul
Re: [DISCUSS] to plugin or not to plugin, that is the question
Posted by Prasad Kashyap <go...@gmail.com>.
On 8/30/07, Paul McMahan <pa...@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.
>
> - 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