You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/09/07 08:30:09 UTC
Merge camel-core, camel-spring and camel-osgi (was Re: Camel, OSGi
and versioning)
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 <cl...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by James Strachan <ja...@gmail.com>.
2009/9/7 Guillaume Nodet <gn...@gmail.com>:
> 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.
Agreed! Plus camel-core/spring/osgi are probably the hardest bits to
get right with Camel + OSGi; so having the simplest possible OSGi
metadata from that single bundle would probably save a ton of OSGi
metadata pain for folks.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@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 <gn...@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 <cl...@gmail.com> wrote:
> >
> >> On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by James Strachan <ja...@gmail.com>.
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 <gn...@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 <cl...@gmail.com> wrote:
>
>> On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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/
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by Charles Moulliard <cm...@gmail.com>.
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 <gn...@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 <cl...@gmail.com> wrote:
>
> > On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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
>
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
I have a question about merge the camel-spring and camel-osgi together.
Since camel-osgi have some dependency of the OSGi related jar,
Is it possible to let new merged camel-spring jar live with Non-OSGi
environment?
Thanks,
Willem
Claus Ibsen wrote:
> On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet<gn...@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.
>>
>
> No I do not think so. We should keep them separated.
>
> Users of Camel uses Camel in non OSGi environments too.
> And non Spring environments as well.
>
> So camel-core should be as light as possible in terms of needed 3rd party .jars.
>
> I only think camel-osgi should be merged to camel-spring if its
> possible to use camel-spring with ANY osgi framework .jars at all.
> Many users use Camel as just a spring web application.
>
>
>
>> On Sun, Sep 6, 2009 at 14:33, Claus Ibsen <cl...@gmail.com> wrote:
>>
>>> On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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
>>
>
>
>
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet<gn...@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.
>
No I do not think so. We should keep them separated.
Users of Camel uses Camel in non OSGi environments too.
And non Spring environments as well.
So camel-core should be as light as possible in terms of needed 3rd party .jars.
I only think camel-osgi should be merged to camel-spring if its
possible to use camel-spring with ANY osgi framework .jars at all.
Many users use Camel as just a spring web application.
> On Sun, Sep 6, 2009 at 14:33, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@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 <wi...@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
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus