+1 for #1,
for the #2, I think we could let the component dependent on the version
ranges of camel-core, camel-spring, camel-osgi.
But for camel-core, camel-spring and camel-osgi, they should dependent
each other with specific version.
Willem
Guillaume Nodet wrote:
I've spotted a few problems in the way the OSGi metadata for camel jars are
computed.
This makes deploying two versions of camel in OSGi nearly impossible.
To fix, I plan to enhance the metadata in two ways:
#1. bundles should not import the packages they export
Here's an example what happen when you do so:
* install bundle A version vx that export foo.bar and import it
the OSGi framework will decide that A export this package because no
other package is available
* install the same bundle in version vy
as some of the packages are already exported by the first version of A,
the OSGi resolver may choose
to have this bundle import the package in version vx (provided that the
version constraints match)
this means that this bundle will not use its own classes for all the
packages that are in common, leading
to obvious problems
So not importing the package means that the OSGi framework will always use
the classes from inside the bundle.
#2. always use version ranges
* For non camel imports, I think the default should be to have a range
equal to [v,v+1) assuming backward compatibility is preserved on minor
releases. So if one bundle has a dependency on foo.bar version 1.1, the
range will be [1.1,2) meaning the framework is allowed to choose any package
with a version >= 1.1 but < 2.0
* for camel imports, this is a bit trickier. I think the default range
should be restricted to minor versions, i.e. [1.1,1.2)
The problem here is to allow someone to update a camel component or core
without updating the whole camel jars, so we need some flexibility on this
range. But usually, I don't think we really ensure full backward
compatibility between minor versions, so having [2.0,3) might not be a good
idea.
Furthermore, this would mean that you can't really deploy two different
minor versions of camel in the same framework, which I think is desirable.
Now, the tricky part is to make sure that we always use consistent classes.
For example when camel-core discover a component, we don't really want
camel-core 1.4 discovering camel 2.0 components, as this would fail. So
the discovery mechanism has to be enhanced to make sure we load compatible
classes.
In OSGi, this can be done by loading a class from the component bundle and
making sure it's the same as our.
For example:
componentBundle.loadClass(org.apache.camel.Endpoint.class.getName()) ==
org.apache.camel.Endpoint.class
This way, the discovery mechanism will be retricted to components that are
actually wired to this camel-core bundle.
So at the end we should be able to:
* deploy multiple versions of camel, provided they have different minor
releases (ex: 1.4, 2.0, 2.1)
* upgrade components / core with micro release (ex: camel-core 2.0,
camel-spring 2.0.2, camel-atom 2.0.1)
And everything should work nicely :-)
I'll start updating the OSGi metadata, but any help would be welcome, as
there are tons of components here !
Also, any volunteer for upgrading and testing the discovery mechanism is
welcomed !
