See comments inline.
Simon
Rajini Sivaram wrote:
Simon,
A few comments inline...
On 5/29/08, Simon Nash <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Rajini Sivaram wrote:
There is no technical reason why we can't store 3rd party jars separately
and merge them at runtime to create "virtual bundles", rather than
distribute "real bundles" containing these manifests. I think the issues
are:
1. The build will be harder and messier since existing tools are not
geared to do this
2. The distribution will be messier from an OSGi perspective
Agreed. How about keeping things simple and clean??
3. OSGi will continue to remain a peripheral feature of Tuscany, never
properly integrated since this is not really mainstream.
Agreed.
4. Real bundles provide more flexibility to OSGi users in terms of
substituting 3rd party jars with newer or patched versions of these, as
well
as avoiding classloading conflicts resulting from version constraints.
Good point too.
My 2c: Generating bundles automatically from JARs is useless. If you want
to leverage OSGi you need to make authoring / fine tuning your
imports/exports a first class part of your development process.
To clarify what I have been saying, I agree with this and I was
expecting that virtual bundles would be constructed in this way.
Even though we can technically generate the exact same manifest entry for
virtual bundles as we would for real bundles, IMHO decoupling manifest
entries which describe very fine grained information about a bundle like the
exact versions of packages it imports from the 3rd party jar and storing it
in the Tuscany distribution in a non-standard way is just the wrong thing to
do. Like we have already shown with itest/osgi-tuscany, virtual bundles
provide a quick and easy way for a large project to get up and running
inside an OSGi runtime. But IMO, the virtual bundle approach has WORKAROUND
written all over it.
I understand this point and I agree that there is value in adopting
an approach that provides the best experience for OSGi users, as long
as this does not create issues in a non-OSGi environment.
I'm starting to feel like a broken record, so I'm going to say it one last
time, for the record. I think we should just follow a simple approach and
add proper (authored) OSGi entries to our JARs and 3rd party dependency
JARs. This doesn't multiply distros, doesn't duplicate JARs, does not
complicate the build. It just makes simple sense IMHO, and other projects
with experience with OSGi are on that path too.
Think of this from a user's perspective. I am downloading Tuscany and
it comes with 149 required dependent bundle-ized 3rd party jars, all at
specific levels chosen by Tuscany, and with Tuscany-specific modifications.
I would like to understand what you mean by "Tuscany-specific
modifications". IMO interoperating with 3rd party jars bundle-ized outside
of Tuscany is not a nice-to-have, it is a must-have. When we bundle-ize a
3rd party jar, all we add are OSGi manifest entries. If we look at the
entries that we add these include
1. Bundle symbolic name : 3rd party jars bundle-ized by Tuscany will use
the name org.apache.tuscany.sca.xxx. Typically applications will never refer
to this name, but in theory they can (eg. to force a bundle to only use
imports from a specific bundle). Use of this name will be a deliberate act
by an user, and hence we dont introduce any interoperability issues by using
a different name.
2. Bundle version and versions of exported packages : Now this is the
most crucial information inside a bundle. It is very crucial that we use the
same versioning conventions as everyone else. Basically this means that
jaxb-impl-2.1.6.jar will use bundle and package version 2.1.6 regardless of
whether it was bundle-ized by Tuscany or anyone else. Regardless of whether
we use virtual bundles or real bundles, this is an absolute must-have for
sharing of classes between applications and Tuscany.
3. Import-Package, Dynamic-ImportPackage and "uses" statements in
Export-Package: The actual packages imported are going to based on what is
imported, and hence should be identical for a bundle regardless of who
bundle-ized it. But there could be (and probably will be) differences in the
constraints used in Import-Package and "uses" clauses in exports. These
constraints are used to achieve sharing and isolation of classes. For
Tuscany, we would probably look at scenarios and tune the constraints for
the most common scenarios. But there is always going to be some application
somewhere which wishes to use a different set of constraints to achieve a
different kind of sharing/isolation. This again comes back to the point that
we have to interoperate with bundles generated by other users. And we
shouldn't make it too tedious for users to replace Tuscany's copies of 3rd
party bundles with their own. IMO, real bundles are much more suited to
complex scenarios involving complex versioning/classloading constraints than
virtual bundles.
Please can you help me understand point 3 better, preferably with a
simple example of constraints that would be used in a bundle created
by Tuscany and what changes a user might want to make to these for
their own purposes. At the moment I don't understand why it isn't
possible to create a bundle that could be used for all purposes.
I can't easily apply the Tuscany modfications to other levels of the
same software that I may need to use in place of the levels distributed
by Tuscany.
Regardless of whether we use virtual bundles or real bundles, manifest
entries from one version of software can't just be used directly on another
level of the same software. If using real bundles, the user has to generate
a new bundle using a tool like maven-bundle-plugin - there is no
Tuscany-specific step here. If using virtual bundles, a new manifest entry
has to be created by the user (again using a tool like maven-bundle-plugin)
and a matching manifest file and jar has to be fed into Tuscany - the
requirement for two matching entities always introduces bigger room for
errors, and this is non-standard.
I also can't easily share the Tuscany versions of these
bundles with my other software that has the same dependencies at identical
or compatible levels.
This is a requirement. It is essential that Tuscany and applications are
able to share classes from Tuscany's versions of 3rd party bundles (eg.
javax.servlet or jaxb) - otherwise we just wouldn't work. And we definitely
dont want to mandate that these applications do anything Tuscany-specific to
enable this sharing.
I'm concerned by the assumption here that Tuscany's versions of
3rd party bundles will be used both by Tuscany and by applications.
An application may be using other software as well as Tuscany, and
this other software may include its own versions of bundles for
javax.servlet or jaxb. If Tuscany requires its versions of these
bundles to be used, and the other software requires its versions
to be used, this requires the application developer to understand
how to resolve any conflicts.
Does this make my life easy? I don't think it does.
At the very least, real bundles will never make life more complicated than
virtual bundles.
From the discussions that have taken place on this thread, I accept
that this is the case. Therefore I would like to focus the ongoing
discussion on how we make real bundles work better for OSGi users
who are integrating multiple software packages (see my comments above)
rather than continuing to debate the pros and cons of virtual bundles.
Simon
