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.
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.
--
Jean-Sebastien
