On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > Jean-Sebastien Delfino wrote: > >> Simon Nash wrote: >> ... snip >> >> I believe that if we are serious about making OSGi-enablement of Tuscany >>>>> a >>>>> first class option, we should consider doing 1). For the longer term to >>>>> support versioning of 3rd party jars, 1) will provide a standard OSGi >>>>> mechanism. As more and more 3rd-party libraries are being OSGi-enabled, >>>>> this >>>>> can be seen as an intermediate step which enables users of Tuscany to >>>>> install Tuscany in the same standard OSGi way, into an OSGi runtime. >>>>> >>>> >>>> I agree and think we should do (1) everywhere we can. >>>> >>>> I don't think Tuscany should modify third-party jars that we >>> are redistributing as part of Tuscany. I think we should use >>> some variant of (3) for all third-party jars that aren't >>> already OSGi-enabled. >>> >>> >> Can you say why? >> >> At the moment we are redistributing these libraries as a convenience > for people who want to run Tuscany "out of the box". If people want > to obtain these libraries in some other way (e.g., from a maven repo, > by direct download from the third-party project, or as part of some > other download), that's fine too. > > This change would alter that picture considerably. For people > using Tuscany within OSGi, it would be necessary to use the modified > libraries distributed by Tuscany.
I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. This might or might not be required > outside the OSGi environment, depending on how we set up the distro > and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. > I looked at ServiceMix4 and I see that it is doing something like > this with the org.apache.servicemix.bundles.* files. For example, > there's one of these that wraps the JAXB implementation in an OSGi > bundle. If we do the same in Tuscany, anyone wanting to use Tuscany > with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB > bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB > implementation classes. Now add SpringSource and a few other > projects into the mix and how many copies of the same JAXB code will > the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. But I imagine disk space for jaxb.jar is not the issue. What we want to minimize is the number of jaxb bundles installed into an OSGi runtime, when ServiceMix, Tuscany etc. etc. are installed into one OSGi runtime. There is nothing stopping Tuscany from using org.apache.servicemix.bundles.jaxb.jar or ServiceMix from using org.apache.tuscany.sca.jaxb.jar, if they can both use the same version. Both of these (and the SpringSource version) have the same versioning conventions and export/imports. Using real bundles, we enable OSGi users to decide which bundles (and how many of them) they want to install into their OSGi runtime. Using virtual bundles, Tuscany will probably end up installing jaxb.jar into OSGi regardless of whether there are other variants that it can use. We are taking control away from the user, and could potentially increase the number of bundles installed unnecessarily, and also potentially generate classloading conflicts. Another more minor point is that for Graham's minimal OSGi test > that's going to be part of the main build, it will be necessary to > build these "wrapper" bundles, increasing the disk space used by > the build because of the need to duplicate the contents of all the > third-party jars, which are already in my local maven repo. As far as I know, Graham's minimal OSGi test is a subset of itest/osgi-tuscany, and hence relies on a manifest.jar file with co-located 3rd party jars (it does not load 3rd party jars directly off the maven repo). The bundle-ized 3rd party jars will replace these vanilla jars, and hence should not have any significant impact on the total disk space used by the build. Simon > > May you could look at what other projects that have spent time working on >> OSGi are doing. Two examples: >> - servicemix 4 >> - springsource app platform >> >> There's probably more good examples out there. >> > > -- Thank you... Regards, Rajini
