Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.220.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=idqZ2jRqZXk5orBCNEi2AJKIunWBN9GcxD//zXxqHJB035lW/kEJBvoHXbx/IsLYHm
         TyP74fcWS5be+dxXYmFB09Hf/J8EL07rhMmFuQhqGjHJkoe+TdO69+QmHi+itn9NirgI
         CHkDMDLT4gmNbMv6zt2IYIrX3PV3vDzadWLWA=
MIME-Version: 1.0
In-Reply-To: <a364c40b0909040142p7216dcfboece0d3edcbf723eb@mail.gmail.com>
References: <b23ecedc0909040122h33afa2edu1000a004a5bfb302@mail.gmail.com>
	 <a364c40b0909040142p7216dcfboece0d3edcbf723eb@mail.gmail.com>
Date: Fri, 4 Sep 2009 13:09:28 +0200
Message-ID: <b23ecedc0909040409o13d6d0e4q6d705060423fcfc7@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=00151747afa4a007220472be88ac

--00151747afa4a007220472be88ac
Content-Type: text/plain; charset=ISO-8859-1

I've attached a patch at
https://issues.apache.org/activemq/browse/CAMEL-1988 and put some
instructions on how to change a given component.

FWIW, I haven't had any time to test the whole thing in OSGi, but that may
mean we need to backport that stuff onto camel-1.x branch, at least to test
it.

On Fri, Sep 4, 2009 at 10:42, Charles Moulliard <cmoulliard@gmail.com>wrote:

> 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 <gnodet@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
> >
>


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

--00151747afa4a007220472be88ac--