On Thu, May 1, 2008 at 1:00 PM, Graham Charters <[EMAIL PROTECTED]> wrote:
> It would seem that the fine-grained/coarse-grained thoughts have > people divided. Rajini's note (aside from the fact she has a tonne of > experience having done most, if not all, of the OSGi work in Tuscany) > paints a picture where the two are not mutually exclusive. I don't > typically like doing two options because that seems like indecision, > but in this case they do appear to complement each other. > > Based on what I've seen in this thread, I'm hoping this briefly > summarizes the collection of thoughts on how we might proceed: > > Tuscany Running in OSGi > > 1. Add bundle manifests to all the Tuscany modules (using maven > bundle plugin). This will ensure the most fine-grained decomposition > works and therefore coarser-grained distributions will also work. > 2. Add a distribution which creates bundles around manageable > collections of Tuscany modules aligned with how we see the runtime > being extended/subsetted/replaced. Have this build and test on > Continuum. > 3. Create 'virtual bundles' for third-party libraries to avoid > licensing and disk space issues (based on Rajini's suggestions, which > I need to better understand). > 4. Provide guidance on the wiki on how to avoid breaking OSGi. > > There's also the suggestion that implementation.osgi relate to > Distributed OSGi (RFC 119), which shouldn't be lost. > > Have I missed anything? > > It sounds like a staging of 1 & 3 first, followed by 2 would work (and > 4 if things keep breaking :-( ). I'd be concerned if we didn't get to > 2, and as part of 1&3, we need to make sure these are regularly tested > under osgi. > > > 2008/5/1 Mike Edwards <[EMAIL PROTECTED]>: > > > > Simon Laws wrote: > > > > > On Thu, May 1, 2008 at 10:03 AM, Rajini Sivaram < > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > > > > My 2c: > > > > > > > > > > +1 to promote OSGi to a first class Tuscany runtime environment > > > > > > > > > > +1 for an OSGi continuum build (thinking about a build profile > that'll > > > > > > > > > run > > > > > > > > > the Tuscany itest suite in an OSGi environment, similar to the > > profiles > > > > > > > > > we > > > > > > > > > have for Web containers for example) > > > > > > > > > > Here's what I imagined we'd do: > > > > > 1. add OSGi entries to each of our JAR manifests > > > > > 2. have developers maintain them and pay attention to > imports/exports > > > > > 3. use the OSGi build to detect API and SPI import/export > violations > > > > > 4. find the best way to OSGi-enable 3rd party dependency JARs > > > > > > > > > > I realize that my suggestion [1] is not very popular and most > people > > on > > > > > this list would prefer to come up with bigger bundles grouping > several > > > > > > > > > of > > > > > > > > > our JARs/modules. I don't think that the 'bigger aggregate bundle' > > > > > > > > > approach > > > > > > > > > will work, but I'll be happy to watch people try it :) if they > want > > to. > > > > > > > > > > With respect to [4] I find rather funny to see many projects out > there > > > > > claim OSGi enablement without having OSGified their 3rd party > > > > > > > > > dependencies. > > > > > > > > > I wonder how that works, can an OSGi-enabled project really > leverage > > the > > > > > OSGi classloader isolation and versioning capabilities when 99% of > the > > > > > > > > > JARs > > > > > > > > > it requires are not OSGi bundles? I must be missing something... > and I > > > > > > > > > hope > > > > > > > > > we can do better in Tuscany with a real end-to-end OSGi enablement > > story > > > > > > > > > :) > > > > > > > > > -- > > > > > Jean-Sebastien > > > > > > > > > > > > > > > > > > I agree with Sebastien's suggestions1-4. But I would like to suggest > a > > > > slight variation to the first suggestion. > > > > > > > > > > > > 1. Use maven-bundle-plugin to introduce OSGi manifest entries into > all > > > > the Tuscany modules, with auto-generated import/export statements. > > > > Modify > > > > itest/osgi-tuscany to run these modules under OSGi, with all 3rd > party > > > > jars > > > > installed into OSGi using virtual bundles created on the fly. > > > > > > > > This step will provide a version of osgi-tuscany tests that is less > > prone > > > > to > > > > breakage than the one we have today. It will also help fix any > remaining > > > > classloading issues that we have left in Tuscany (and hopefully help > > > > in maintaining the classloader isolation). This is not a big piece > of > > work > > > > since this is just bringing together the different pieces that we > > already > > > > have. I will be happy to contribute the code towards this first > step, so > > > > others can concentrate on what we really want to achieve in terms of > > > > modularity, distribution etc. We can also use this step to explore > > > > versioning - in particular about having multiple extensions > referring to > > > > different versions of 3rd party libraries. This will be very useful > for > > 4. > > > > > > > > Suggestions 2-3 are not requirements for OSGi, but these are clearly > > cases > > > > where OSGi technology can help Tuscany improve modularity. If we > want to > > > > have explicitly hard-coded import/export statements in the modules > to > > > > enforce modularity, that can be introduced in step 2. > > > > > > > > And I would expect that there will be more work in terms of building > the > > > > distributions suitable for OSGi as well as non-OSGi after 1-4. > > > > > > > > > > > > > > > > > > > > Thank you... > > > > > > > > Regards, > > > > > > > > Rajini > > > > > > > > > > > > > > Re. modularity, it strikes me that there is lack of consensus about > > whether > > > big bundles or small bundles, relative to our maven modules, are > > preferable > > > but that there is consensus about using OSGi bundles to help us test > and > > > refine out modularity story. > > > > > > So maybe we should agree to disregard the question about how big OSGi > > > bundles should be relative to our maven modules and concentrate on the > > > question about whether our maven modules are correctly factored. Using > > OSGi > > > as a tool to help us with this of course. > > > > > > Simon > > > > > > > > I support both Rajini's and Simon's points. We can get the mechanics > going > > first with the bundles following the existing grain of the modules - and > we > > can discuss and tinker with the modules as we please later to find the > best > > arrangements. > > > > I suspect that the differing opinions about module size reflect > different > > usecases. Lots of small modules can promote great flexibility in the > > construction of runtimes, but at the expense of making it much harder > for > > users to make sense of the options. Larger modules cut down the options > but > > make things easier for end users. > > > > > > Yours, Mike. > > > I would further propose that we take a subset of the output of 1 and 3, for example, enough to run the calculator sample, as an initial test case separate from the full range of itest/osgi-tuscany tests. This would give us something to shoot re. inclusion in the regular build. Simon
