You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2009/09/07 08:36:07 UTC
Re: Merge camel-core, camel-spring and camel-osgi (was Re: Camel,
OSGi and versioning)
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
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
>>
>
>
>