Hello, Following on from the discussion in thread [1], and based on Sebastien's comments [2], we need to make a decision on the best way forward to OSGi-enable third party libraries used by Tuscany.
The options we have are: 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany distribution. Existing OSGi tools like maven-bundle-plugin and maven-pax-plugin can be used to generate these bundles. The new manifest entries will not have any impact when Tuscany is run outside OSGi. For signed jars and jars with license restrictions, it may be necessary to generate a bundle with the jar embedded into it, resulting in separate jars for OSGi and non-OSGi. But these should hopefully be small in number. 2. Use non-OSGi mechanism to enable Tuscany bundles running inside OSGi to refer to jars outside OSGi. 3. Create virtual bundles on the fly for 3rd party jars. At the moment, itest/osgi-tuscany does this using auto-generated naive manifests. If we are to use virtual bundles going forward, manifest entries for the virtual bundles should be created at build time, and stored in one of the Tuscany jars. 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. 3) works, and looks easier to roll out, but I would imagine that OSGi users of Tuscany would end up creating their own variants of 1) if we support only 3). And it feels like a wrapper (or rather it is a wrapper), with manifests and their matching 3rd party libs stored separately. Thoughts? [1] http://markmail.org/message/tybuyxoaddjjrpbx [2] http://markmail.org/message/wbuixok3x3hazjqq Thank you... Regards, Rajini
