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 cmoulliard@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=ZwV1MyFpYehvLegCi7CHxw/Hkvc3mryhiNKCAwroAQ8sztm98XZyW/3pkCXCS2D+Hz
         YtBQZwUSREJ1w3so6ERS5meecidsU7wQYnEHjMZVGuEfQemo5I283D5qqdIljFN42VLk
         CcpTAu1wPhbDqBO7ahJz9xN1xdzilgyXeUgsY=
MIME-Version: 1.0
In-Reply-To: <b23ecedc0909062330i3f320e7ele4b76d18750aca9@mail.gmail.com>
References: <b23ecedc0909062330i3f320e7ele4b76d18750aca9@mail.gmail.com>
Date: Mon, 7 Sep 2009 09:17:59 +0200
Message-ID: <a364c40b0909070017r14a4e24ak21c1d95515e8e9da@mail.gmail.com>
Subject: Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
	OSGi and versioning)
From: Charles Moulliard <cmoulliard@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=001517478ae448df480472f7a6db

--001517478ae448df480472f7a6db
Content-Type: text/plain; charset=ISO-8859-1

I'm not quite sure that this is a good idea to merge camel-core and
camel-spring. Until now, we have three expressions languages :

1) Java DSL : camel-core
2) Spring DSL : camel-spring
3) Scala DSL : camel-scala
...

Even if java and spring DSL are the most used, we have no idea about what
the future will be. If we merge camel-spring and camel-core, why don't we
merge camel-scala and camel-core too. In term of testings, unit tests are
also separate. Java DSL unit tests are defined in camel-core while spring
DSL unit tests (which extended the Java unit tests) are packaged in spring
DSL. So, it is better to keep them separate.

Nevertheless, classes used to inject dependency could be packaged within
camel-core (idem for camel-guice) ?
And for the stuffs related to OSGI world where we need spring OSGI,
blueprint, ... a separate jar/bundle should exist ?

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*****************************
blog : http://cmoulliard.blogspot.com


On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet <gnodet@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.
>
> On Sun, Sep 6, 2009 at 14:33, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>
> > On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<willem.jiang@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.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 !
> > >>>>
> > >>>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> > --
> > 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
>

--001517478ae448df480472f7a6db--