On 5/12/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Rajini Sivaram wrote: > > > At the moment, itest/osgi-tuscany generates a manifest jar file called > > tuscany-sca-manifest.jar using a copy of the pom in distribution. I was > > hoping that we could use a single jar for both OSGi and non-OSGi. The > > list > > of virtual 3rd party bundles to be installed and the location of their > > plain > > jar files is based on the Class-Path entry in this > > tuscany-sca-manifest.jar. > > I do understand that this jar doesn't work in Eclipse, but I am not sure > > what we gain by having an additional jar for OSGi rather than reuse the > > jar > > which is already in distribution. Are we planning to get rid of > > tuscany-sca-manifest.jar in distribution? > > > > > Here's what really puzzles me: > > a) We want to use OSGi as it allows us to cut Tuscany in self contained > and isolated bundle JARs, enables us to pick the right subsets of JARs for a > particular environment, can even enable us to combine different levels of > dependency JARs when required by our extensions. > > b) But now all the info for all the dependency JARs is mashed in a single > tuscany-sca-manifest.jar, and frozen in that 'manifest' JAR when we build > the Tuscany distribution. > > Sorry, but I'm having a hard time understanding how to reconcile (a) and > (b).
We are learning to walk (or in this case crawl), before starting to run. (b) is a temporary step - it is the way it is purely because I work on Tuscany in my (rather non-existent) free time. And it was meant to provide something for Graham to get started on. > Can't it just be much simpler than that? > - 1 bundle per dependency JAR > - containing the OSGi metadata describing that JAR and what it actually > imports/exports? Yes, that is the goal. But unfortunately this is not "simpler" - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. > This is the approach that SpringSource for example seems to have chosen > for they application platform OSGi repository. IMHO they are on the right > path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). From what I have seen and heard so far, Tuscany seems very reluctant to take that step. We still seem to take the view that OSGi is an add-on, something that we would like to use (maybe, but not quite so sure yet). And that is part of the problem. OSGi tools are geared for building OSGi bundles - maven-pax-plugin for instance would be easy to use for converting our third party jars to bundles. It is slightly harder (messier, but not impossible) to just generate the meta-data we need for using virtual bundles. And we still haven't addressed the issue of bundle dependencies - how do we decide which bundles to install? Do we go for something like OBR in Felix, or invent something else? SpringSource have their own implementation of repositories. Having 100 separate 3rd party bundles (virtual or otherwise) doesn't make sense until we also have a mechanism for automagically determining dependencies across bundles and installing the required bundles. We need additional meta-data apart from the manifest entries to enable this. I do agree that all this needs to be done to get the full benefit of OSGi - I just feel that it requires a lot more thought. > -- > Jean-Sebastien > -- Thank you... Regards, Rajini
