camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel, OSGi and versioning)
Date Mon, 07 Sep 2009 07:45:27 GMT
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 <james.strachan@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 <gnodet@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 <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
> >
>
>
>
> --
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message