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