On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<willem.ji...@gmail.com> wrote: > Because there are some internal API dependencies between the camel-core , > camel-spring. I'm not sure if the OSGi version range can help us to find out > the minor internal API change. >
Yeah camel-core and camel-spring are really to tightly coupled that running with different version of them is not recommended. Eg routing with XML depends on camel-spring where as the routing model is in camel-core etc. So it make most sense to support upgrading various other camel components such as for example camel-jetty, camel-http, camel-velocity etc. > Willem > > Guillaume Nodet wrote: >> >> On Fri, Sep 4, 2009 at 11:22, Willem Jiang <willem.ji...@gmail.com> wrote: >> >>> +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. >>> >>> >> Why ? This would prevent from upgrading one of those bundles without >> upgrading the others. >> >> >>> 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 ! >>>> >>>> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
