On 8/30/07, Joe Bohn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
