Sorry for the long delay in responding. I have been deeply buried
in implementing the new WSDL-less support, and I am only just
surfacing to follow up on other threads. Comments inline.
Simon
Rajini Sivaram wrote:
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.
I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle
jars downloaded from elsewhere to work with Tuscany running under OSGi. If
there is a requirement, we can support virtual bundles with naive manifests
just for these cases. I am not sure that is reason enough for virtual
bundles to be the only (or default) option.
On the other hand, I would think that OSGi users of Tuscany may expect 3rd
party bundle jars from other projects like ServiceMix to work with Tuscany
running under OSGi. We can easily support that with bundle-ized jars.
It would be great to have some co-ordination between these projects
so that they can share the same bundle-ized 3rd party jars rather
than all creating their own copies and giving the user the problem
of figuring out whose version of bundle-ized jaxb can be used with
Tuscany, ServiceMix, Spring, etc.
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.
For users who run Tuscany outside of OSGi, we can (and should) continue to
support third party libraries downloaded from anywhere. I dont think
bundle-izing 3rd party libraries will require any changes to the way
extensions locate their third party dependencies.
If the bundle-izing is only intended for use by the native OSGi Tuscany
runtime, could we produce a separate distro that contains the native
OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current
binary distro is very large and it would not be good to have it contain
a complete set of unmodified 3rd party jars and another complete set
of the same jars in bundle-ized form. I would also not be keen to
change the regular binary distro to only contain bundle-ized jars
as I think this will be confusing for non-OSGi users of Tuscany,
especially if they don't want to use the exact levels of the 3rd-party
jars that Tuscany has decided to bundle-ize.
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.
If you install ServiceMix4 and Tuscany, at the moment you will have
org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk.
Using real bundles, we will replace Tuscany's jaxb.jar with
org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system.
Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to
org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk
space is where Tuscany's jaxb.jar is shared with other products running
outside OSGi.
As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary
distro by org.apache.tuscany.sca.jaxb.jar. If this is within the
context of a separate OSGi-specific binary distro, I would be OK
with including bundle-ized jars in that distro.
But I imagine disk space for jaxb.jar is not the issue. What we want to
minimize is the number of jaxb bundles installed into an OSGi runtime, when
ServiceMix, Tuscany etc. etc. are installed into one OSGi runtime. There is
nothing stopping Tuscany from using org.apache.servicemix.bundles.jaxb.jar
or ServiceMix from using org.apache.tuscany.sca.jaxb.jar, if they can
both use the same version. Both of these (and the SpringSource version) have
the same versioning conventions and export/imports. Using real bundles, we
enable OSGi users to decide which bundles (and how many of them) they want
to install into their OSGi runtime. Using virtual bundles, Tuscany will
probably end up installing jaxb.jar into OSGi regardless of whether there
are other variants that it can use. We are taking control away from the
user, and could potentially increase the number of bundles installed
unnecessarily, and also potentially generate classloading conflicts.
If all the versions of bundle-ized jaxb are the same in terms of
versioning and exports/imports, this can work as you say. Is there
any chance of the OSGi community establishing a maven repo to host
these bundle-ized jars, with a suitable naming convention, so that
they can just be created once rather than n times by every project
that wants to use them?
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.
As far as I know, Graham's minimal OSGi test is a subset of
itest/osgi-tuscany, and hence relies on a manifest.jar file with co-located
3rd party jars (it does not load 3rd party jars directly off the maven
repo). The bundle-ized 3rd party jars will replace these vanilla jars, and
hence should not have any significant impact on the total disk space used by
the build.
I had expected that the "virtual bundle" approach would be able to
load unmodified jars from the maven repo, combining them with separate
manifests containing the version/export/import information. Is there
some reason why this can't be done?
Simon
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.
