One comment inline.
Simon
Jean-Sebastien Delfino 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.
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.
Simon
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
