Will do. Still working on that. I'm working on camel-core and camel-spring and will commit when I have something that looks good.
Btw, anyone know why the flag camel.osgi.exclude.dependencies is set to true ? It seems it makes the maven bundle plugin ignore versions from the dependencies. Without this flag, we can't have default computed version ranges. On Fri, Sep 4, 2009 at 10:42, Charles Moulliard <cmoulli...@gmail.com>wrote: > 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
