Hi Raymond, thanks for your comments. I've added some more below. Regards, Graham.
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>: > More comments inline. > > Thanks, > Raymond > -------------------------------------------------- > From: "Graham Charters" <[EMAIL PROTECTED]> > Sent: Wednesday, April 30, 2008 9:43 AM > > To: <[email protected]> > Subject: Re: Improving support for running in OSGi > > > > 2008/4/30 Raymond Feng <[EMAIL PROTECTED]>: > > > > > "Enforcing" the modularity via OSGi is a good way to validate our > > > modularity/extensibility story in Tuscany. I think we already have a > fairly > > > well organized module structure in Tuscany (from the maven dependency > > > perspective). To be consistent, should we consider directly mapping our > > > module structure into OSGi bundles (one bundle per existing Tuscany > module)? > > > > > > > > > > I wonder if that might be too fine-grained and unmanageable. > > Personally, I'd prefer an approach which took into consideration how > > we see folks extending or sub-setting the runtime (e.g. the things > > Yang referred to - implementation types, etc.). > > > > > > IMHO, big bundles lead to defeat modularity and increase coupling. It also > become difficult to embed subset of the Tuscany runtime. But anyway, we can > adjust the scheme over time as the picture becomes clearer. > > To a certain extent I agree with you, but there's also a school of thought that says when adopting OSGi it's best to start with big modules and then decompose as understanding grows. I think the thought processes we go through will ensure we end up with the right modules that match the requirements, such as runtime subsetting. > > > > > > There may be different levels for the OSGi enablement. > > > > > > 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars > can be > > > consumed as OSGi bundles > > > 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the > > > modularization mechanism for the Tuscany runtime, system level) > > > > > > > I think we need this step to occur regularly and frequently to stop > > the support decaying. I've fixed these kinds of issues twice in the > > last week, which occur because new modules are added to Tuscany, but > > not the OSGi support (not surprising since the OSGi support is outside > > the main build). > > > > > > Is there a checklist we can use to make sure new modules or changes won't > break the OSGi support? If not, can we produce one and post it to the > Tuscany wiki? > > I think we could produce a checklist to help folks. It would also be nice to make it easier for people to get things right without it. The idea of updating the module structure to reflect the bundles we create is interesting. I guess if the number of bundles is changing rapidly then this might be a bit painful. We could also have the bundles build on continuum so we find problems earlier. Having everyone build the bundles might not be acceptable. > > > > > > 3) Support OSGi bundles as SCA contributions (application level, how > does > > > the OSGi import/export relate to the sca-contributions.xml?). > > > > > > The other interesting issue is how we deal with the 3rd party jars, > most of > > > which are not OSGi bundles. To support the case that different Tuscany > > > extensions may require different versions of the same 3rd party jar, we > need > > > to figure out a good way to "turn" 3rd party jars into OSGi bundles. > > > > > > > > > > This is a knotty problem. It's not a new problem and is discussed > > here: https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/000023.html > > > > Licensing and signing can prevent us from adding information to the > > jars, which leaves us with three options, I think: > > > > 1. Create wrapper bundles which contain the jars, which raises > > concerns about disk space. > > 2. Use a non-OSGi mechanism to refer to jars outside a bundle > > (Equinox allows this). > > 3. Devise a new mechanism to create 'virtual bundles' on the fly (see > > https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277). > > > > > > Unfortunately, the URL requires a log-in. Is it possible to post the > content here? > My apologies, I hadn't realized this was a member bug and therefore required access (I must have already been logged in when I tested it). I can't paste in the details, but I can summarize. This bug discusses the requirement raised in the first link. It discusses the approach to allow the bundle classpath to reference jars outside the bundle (the equinox approach), and also considers a 'virtual bundle' concept (which seems preferred). There aren't many details about the latter. > > > > > 3 might be the best solution longer term, but is the most work. > > > > > > > Thanks, > > > Raymond > > > > > > -------------------------------------------------- > > > From: "Yang Lei" <[EMAIL PROTECTED]> > > > Sent: Tuesday, April 29, 2008 9:09 PM > > > To: <[email protected]> > > > Subject: Re: Improving support for running in OSGi > > > > > > > > > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > >
