Hi Guillaume, I have been confronted yesterday to the problem that you describe here (moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use version range as they assume also a certain level of compatibility within release. It means also that before to commit every new change, developers have top take care about versioning ;-)
I propose to work on the following components as I use them in my platform : camel-bindy, camel-jms, camel-ognl, camel-stream, camel-quartz, camel-spring Can you provide an example that I can use to adapt components mentioned. When modifications will be done, I will test them within my project Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer ***************************** blog : http://cmoulliard.blogspot.com On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gno...@gmail.com> 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 ! > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >