Graham Charters wrote:
FWIW, I agree with Sebastien and Rajini. I don't believe it's a
coincidence that both SpringSource and ServiceMix went the route of
adding manifests to the thirdparty jars. It keeps things simple and
gives a better experience from an OSGi perspective. If we're serious
about supporting OSGi we should try to do the right thing by the
technology.
See my recent response to Sebastien's post on this. There are clearly
some different perspectives here about what is simple. It seems to me
that this is only simple for people using Tuscany SCA out of the box
together with its 149 dependencies at the specific levels distributed
by Tuscany. For other combinations, I don't see how sinmplicity for
the user is achieved. Please help me understand how this approach
would solve the use case that I have in mind.
Whilst not necessarily an argument against virtual bundles, I also
agree that we should have properly authored dependencies. This view
is supported by the discussion Rajini is having in Jira 2343. I know
for a fact that SpringSource work very hard to ensure the version
ranges on their dependencies are sensible (e.g. match the rules
governing version increments for each project).
Agreed.
Simon
I don't believe we can completely do away with virtual bundles in the
short term, but we should only use them where necessary (e.g for
signed jars and jars which require code extensions to function in
OSGi).
Regards, Graham.
2008/5/29 Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
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
