No problems for me. Though I wonder if this reflects something that have to be enhanced / modified. If those jars are so closely related, wouldn't it make sense to have only one ? I've already suggested merging camel-spring and camel-osgi some time ago, but I know wonder if they should be moved into camel-core directly. The other fact that leads me this way is the fact that some components actually depend on camel-spring classes.
On Sun, Sep 6, 2009 at 14:33, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
