On 9/2/07, Karl Pauls <[EMAIL PROTECTED]> wrote: > On 9/2/07, David Jencks <[EMAIL PROTECTED]> wrote: > > > > On Sep 2, 2007, at 8:36 AM, Karl Pauls wrote: > > > > > On 8/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > >> On 8/30/07, Paul McMahan <[EMAIL PROTECTED]> 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 > > > [EMAIL PROTECTED] > > > > > > > -- > Karl Pauls > [EMAIL PROTECTED] > -- Karl Pauls [EMAIL PROTECTED]
