On Thu, May 15, 2008 at 3:13 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Rajini Sivaram wrote: > >> 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. >> > > I agree and think we should do (1) everywhere we can. > > >> 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. >> > > How about an interim variation of (3) for the 3rd party JARs that we > initially can't cover with (1): > > For each 3rd party foo.jar, a foo-osgi.jar containing the bundle manifest > that'll turn foo.jar into an OSGi virtual bundle, and I mean a proper bundle > manifest with actual specific imports / exports instead of the naive *. > > I'm just throwing this up in the air to see any reactions from OSGi-skilled > people in the group :) > > Maybe it's a stupid idea? but that would provide the level of modularity > that we're expecting from OSGi, instead of mashing everything up in a > central tuscany- manifest.jar which pretty much kills the benefits of using > OSGi IMO. > > >> >> Thoughts? >> >> >> [1] http://markmail.org/message/tybuyxoaddjjrpbx >> [2] http://markmail.org/message/wbuixok3x3hazjqq >> >> Thank you... >> >> Regards, >> >> Rajini >> >> > -- > Jean-Sebastien > I agree that, for 3, I don't see why we have to put all the manifests one place. If we have an input lib dir such as 3rdpartylib1.jar 3rdpartylib2.jar 3rdpartylib3.jar Why wouldn't the result of creating manifests for virtual use be... 3rdpartylib1.jar 3rdpartylib1.mf (or 3rdpartylib1-mf.jar if that is better?) 3rdpartylib2.jar 3rdpartylib2.mf 3rdpartylib3.jar 3rdpartylib3.mf And have the naming convention allow the manifests to be picked up and used to create virtual bundles of the jars.. More generally, and regardless of whether option 1 or 3 is used, when we install these jars into OSGi are we expecting other applications to be able to use them or are we calculating exports just based on what Tuscany uses? Simon
