Re: [DISCUSS] to plugin or not to plugin, that is the question
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
Re: [DISCUSS] to plugin or not to plugin, that is the question
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 :-) 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]
Re: [DISCUSS] to plugin or not to plugin, that is the question
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 :-) 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 [EMAIL PROTECTED]
Re: [DISCUSS] to plugin or not to plugin, that is the question
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:
Re: [DISCUSS] to plugin or not to plugin, that is the question
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
[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
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
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. - 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
Re: [DISCUSS] to plugin or not to plugin, that is the question
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
