Yeah, I was kinda thinking the same. If those bundles are tightly bound together, it would make sense to have a single bundle. Too many fine grained bundles isn't a good thing either in OSGi.
On Mon, Sep 7, 2009 at 09:41, James Strachan <james.strac...@gmail.com>wrote: > Maybe camel-osgi could include camel-core and camel-spring in a single > bundle? > > Folks who don't use spring or osgi can use camel-core; folks can then > add camel-spring if they want - but maybe folks using osgi can have a > single bundle with camel+osgi+spring which is a very common > combination in osgi - and it would let us simplify & fix up the osgi > metadata a bit? > > I guess some folks might wanna use osgi camel without spring; but > maybe camel-osgi's spring dependency could be made optional? > > > 2009/9/7 Guillaume Nodet <gno...@gmail.com>: > > 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 > > > > > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
