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
>

Reply via email to