On 5/15/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > 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..
100 extra manifest files in the distribution directory - hmm... If we do want to generate manifest files for virtual bundles, IMO packaging of this should be discussed along with the bundle provisioning mechanism and the meta-data required to maintain bundle dependencies (OBR repository.xml or whatever we choose to use). 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? Regardless of 1 or 3, we would use - bundle symbolic name that starts with org.apache.tuscany.sca to distinguish 3rd party jars that Tuscany bundle-ized from 3rd party jars which are already bundles - bundle version that corresponds to the actual jar version (eg. xercesImpl-2.8.1.jar will have Bundle-Version 2.8.1) - export all packages from bundle - export/import calculations for 3rd party jars are completely independent of Tuscany Other applications will be able to use these 3rd party bundles. > Simon > -- Thank you... Regards, Rajini
