On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet<gno...@gmail.com> wrote: > 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. >
No I do not think so. We should keep them separated. Users of Camel uses Camel in non OSGi environments too. And non Spring environments as well. So camel-core should be as light as possible in terms of needed 3rd party .jars. I only think camel-osgi should be merged to camel-spring if its possible to use camel-spring with ANY osgi framework .jars at all. Many users use Camel as just a spring web application. > 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 > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
