Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates
 209.85.218.216 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=FI10uvBjn0tdvd2HBbHAwGC8u3+B1U17Xguqlrr6hgL0L4lZU78mQQyN9Em9EouwRX
         X2oI1R4gBN+n9NL/1XHtSguXLQruwHdIMmRDDFGUOryhc1YLjbd6jR+WSE0C+O0wRkvM
         QDhhpWXpW3SuGOixkH7FYMEd3RnvDMmYiDHFQ=
MIME-Version: 1.0
In-Reply-To: <4AA0DC39.5010908@gmail.com>
References: <b23ecedc0909040122h33afa2edu1000a004a5bfb302@mail.gmail.com>
	 <4AA0DC39.5010908@gmail.com>
Date: Fri, 4 Sep 2009 11:30:50 +0200
Message-ID: <b23ecedc0909040230o1f975cebpf279efaa76c15f8c@mail.gmail.com>
Subject: Re: Camel, OSGi and versioning
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=0015173fe6c6e3c6360472bd27bb

--0015173fe6c6e3c6360472bd27bb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 4, 2009 at 11:22, Willem Jiang <willem.jiang@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 !
>>
>>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

--0015173fe6c6e3c6360472bd27bb--