FYI, SpringSource now has an Enterprise Bundle Repository:
http://www.springsource.com/repository/app/
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 12:12 AM
To: <tuscany-dev@ws.apache.org>
Subject: Re: OSGi-enable 3rd party libraries in Tuscany
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
