Rajini Sivaram wrote:
Can we decide on a solution for OSGi-enabling 3rd party libs (either in the
distribution or using virtual bundles), so that we can start tackling issues
like versioning (https://issues.apache.org/jira/browse/TUSCANY-2343)?
I just replied to your previous message on this. Sorry for the
long delay in responding. I have been deeply buried in the WSDL-less
support for the last couple of weeks.
Simon
On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Simon Nash wrote:
... snip
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.
Can you say why?
At the moment we are redistributing these libraries as a convenience
for people who want to run Tuscany "out of the box". If people want
to obtain these libraries in some other way (e.g., from a maven repo,
by direct download from the third-party project, or as part of some
other download), that's fine too.
This change would alter that picture considerably. For people
using Tuscany within OSGi, it would be necessary to use the modified
libraries distributed by Tuscany. This might or might not be required
outside the OSGi environment, depending on how we set up the distro
and the way our extensions locate their third-party dependencies.
I looked at ServiceMix4 and I see that it is doing something like
this with the org.apache.servicemix.bundles.* files. For example,
there's one of these that wraps the JAXB implementation in an OSGi
bundle. If we do the same in Tuscany, anyone wanting to use Tuscany
with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB
bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB
implementation classes. Now add SpringSource and a few other
projects into the mix and how many copies of the same JAXB code will
the user need? Any number greater than one is the wrong answer.
Another more minor point is that for Graham's minimal OSGi test
that's going to be part of the main build, it will be necessary to
build these "wrapper" bundles, increasing the disk space used by
the build because of the need to duplicate the contents of all the
third-party jars, which are already in my local maven repo.
Simon
May you could look at what other projects that have spent time working on
OSGi are doing. Two examples:
- servicemix 4
- springsource app platform
There's probably more good examples out there.
