Irrespective of the versioning question, the current 5 module breakdown does not go as far as individual implementation types, binding types and so on. I'm presuming here that the goal would be to be able to add/remove/replace things at that level rather than requiring the entire 'extensions' bundle to be refreshed, for example?
2008/4/30 Simon Nash <[EMAIL PROTECTED]>: > Yang Lei wrote: > > > I think enabling OSGI can help modularity with a clear definition of > > package visibility, so we can have a much cleaner "module" > > dependencies through osgi bundle import/export on package. I think > > it will help Tuscany adopters a lot in the scenarios such as: when > > implementing new implementation type, binding type, or data binding > > types, there is clear indication which set of packages can be used > > (exported API/SPI ). So upgrading to new Tuscany level can be as > > simple as plug and play if there is no API/SPI changes, and version > > control (multiple version co-existence) can also be made available > > through OSGI capabilities. > > > > > +1 for the benefits to modularity. For versioning, I see the value > more in terms of allowing multiple versions of third-party dependencies > to coexist, rather than having multiple versions of some parts of > Tuscany loaded at the same time. Are there any scenarios that would > require the latter? > > Simon > > > > > > Regards, > > > > Yang > > > > On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT) > > <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > > OSGi is a good one, > > > > > > > IMHO support of OSGi is very important and I glad to see increasing > interest of the community here. > > > > > > > > > > and get ideas on how best to proceed. > > > > > > > I personally have currently not a very deep insight into implementation > details yet, but we are currently prototyping and have there also OSGi > services. > > > What I could offer today is only to feed our findings about limitations > and rooms for improvement back. > > > Another important thing which I see on the horizon, is the ongoing > standardization of Distributed OSGi (RFC119) and the benefit to support that > standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to > keep an eye on that as well. > > > > > > Regards, > > > Philipp > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Graham Charters [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 28. April 2008 09:48 > > > An: [email protected] > > > Betreff: Improving support for running in OSGi > > > > > > > > > Hi All, > > > > > > I'd like to get more involved in the OSGi support in Tuscany (both the > > > modularity work (itest/osgi-tuscany) and the implementation.osgi). I > > > recently started looking at the work to run Tuscany in OSGi, embodied > > > in itest/osgi-tuscany and described in the thread entitled > > > "Classloading in Tuscany". I've noticed a couple of others on the > > > list also interested in Tuscany running in OSGi and wondered if it > > > might be worth considering making this a "first-class" option. At the > > > moment the five bundles are only built by folks who want the OSGi > > > support and go into the itest/osgi-tuscany directory to create it. > > > This can result in any problems being discovered late, but also could > > > create the impression that OSGi is considered a second-class > > > environment (which I don't believe is the case). > > > > > > Aside from the obvious benefits to OSGi users in doing this, I think > > > there's a potential for Tuscany to use the OSGi build as a test-bed > > > for highlighting and working through modularity issues, which would > > > also benefit Tuscany in general, not just in an OSGi runtime. > > > > > > I'd like to get people's thoughts on whether the idea of 'promoting' > > > OSGi is a good one, and get ideas on how best to proceed. We could > > > then start discussing what some of the issues might be (e.g. size of > > > builds, time to build, etc...). > > > > > > Regards, > > > > > > Graham. > > > > > > > > > > > > > >
