You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Aki Yoshida <el...@gmail.com> on 2015/08/05 11:38:23 UTC
How to avoid getting two servicemix-specs versions when installing
camel or cxf 's feature
Originally, I posted the following mail to dev@camel regarding this issue.
http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
Currently, both camel and cxf have their features that directly
installing some servicemix-specs bundles. This leads to the problem
mentioned in the above mail thread that installing camel-cxf leads to
installing two versions of servicemix-spec because camel-2.15.2 is
using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
using smx-specs 2.4.0.
I am wondering if we need to define this feature (e.g., feature
stax-api-1.0) outside of camel and cxf and both refer to this external
feature using the appropriate version range e.g. [2.2,3) or we can
locally solve this problem within camel and cxf's feature definitions?
I would appreciate for your comments.
regards, aki
Re: How to avoid getting two servicemix-specs versions when
installing camel or cxf 's feature
Posted by Guillaume Nodet <gn...@apache.org>.
I think another generic solution would be to make sure the specs are
flagged as dependencies, so that Karaf can pick up only one bundle to solve
those.
2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi Aki,
>
> We have different ways:
> 1/ we "align" CXF and Camel to the same spec bundle version. As spec
> bundles are pretty stable in term of release, I think it's probably the
> easiest move, but we don't actually fix the problem if we use old version
> of one of the two.
> 2/ remove spec from CXF and Camel and put a spec feature directly in
> Karaf, as we do for jetty, etc.
> 3/ provision spec bundle in the lib folder as we do for activator spec
> bundle
>
> Probably 2 would make sense. Anyway, we will have to update CXF and Camel
> to refer to provided spec feature. With Karaf 4 and the new feature
> resolver, it would be better to use feature requirements and let the
> resolver deals with spec bundle.
>
> Regards
> JB
>
>
> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>
>> Originally, I posted the following mail to dev@camel regarding this
>> issue.
>>
>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>
>> Currently, both camel and cxf have their features that directly
>> installing some servicemix-specs bundles. This leads to the problem
>> mentioned in the above mail thread that installing camel-cxf leads to
>> installing two versions of servicemix-spec because camel-2.15.2 is
>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>> using smx-specs 2.4.0.
>>
>> I am wondering if we need to define this feature (e.g., feature
>> stax-api-1.0) outside of camel and cxf and both refer to this external
>> feature using the appropriate version range e.g. [2.2,3) or we can
>> locally solve this problem within camel and cxf's feature definitions?
>>
>> I would appreciate for your comments.
>>
>> regards, aki
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
RE: How to avoid getting two servicemix-specs versions when
installing camel or cxf 's feature
Posted by "Pratt, Jason" <Ja...@windriver.com>.
#2 sounds like it'd give the developer/admin more control
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Wednesday, August 05, 2015 12:17 PM
To: user@karaf.apache.org
Subject: Re: How to avoid getting two servicemix-specs versions when installing camel or cxf 's feature
Hi Aki,
let's see what the others think: if all agree, I will go for approach 2.
Regards
JB
On 08/05/2015 07:12 PM, Aki Yoshida wrote:
> Hi JB,
>
> Thanks for the explanation.
>
> For the current snapshot version of camel (2.16-SNAPSHOT and
> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
> If the spec features are made available in one of the Karaf's repos as
> in approach 2, that will be great. This can avoid this problem for
> other combination in the future or with a combination with other
> components that also can use this shared features to avoid getting
> into this problem.
> Will you be providing the spec features as in approach 2?
>
> Regards, aki
>
>
>
> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi Aki,
>>
>> We have different ways:
>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec
>> bundles are pretty stable in term of release, I think it's probably
>> the easiest move, but we don't actually fix the problem if we use old
>> version of one of the two.
>> 2/ remove spec from CXF and Camel and put a spec feature directly in
>> Karaf, as we do for jetty, etc.
>> 3/ provision spec bundle in the lib folder as we do for activator
>> spec bundle
>>
>> Probably 2 would make sense. Anyway, we will have to update CXF and
>> Camel to refer to provided spec feature. With Karaf 4 and the new
>> feature resolver, it would be better to use feature requirements and
>> let the resolver deals with spec bundle.
>>
>> Regards
>> JB
>>
>>
>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>
>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>
>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-featur
>>> e-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5
>>> 769830.html
>>>
>>> Currently, both camel and cxf have their features that directly
>>> installing some servicemix-specs bundles. This leads to the problem
>>> mentioned in the above mail thread that installing camel-cxf leads
>>> to installing two versions of servicemix-spec because camel-2.15.2
>>> is using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>> using smx-specs 2.4.0.
>>>
>>> I am wondering if we need to define this feature (e.g., feature
>>> stax-api-1.0) outside of camel and cxf and both refer to this
>>> external feature using the appropriate version range e.g. [2.2,3) or
>>> we can locally solve this problem within camel and cxf's feature definitions?
>>>
>>> I would appreciate for your comments.
>>>
>>> regards, aki
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to avoid getting two servicemix-specs versions when installing
camel or cxf 's feature
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Aki,
let's see what the others think: if all agree, I will go for approach 2.
Regards
JB
On 08/05/2015 07:12 PM, Aki Yoshida wrote:
> Hi JB,
>
> Thanks for the explanation.
>
> For the current snapshot version of camel (2.16-SNAPSHOT and
> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
> If the spec features are made available in one of the Karaf's repos as
> in approach 2, that will be great. This can avoid this problem for
> other combination in the future or with a combination with other
> components that also can use this shared features to avoid getting
> into this problem.
> Will you be providing the spec features as in approach 2?
>
> Regards, aki
>
>
>
> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi Aki,
>>
>> We have different ways:
>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
>> are pretty stable in term of release, I think it's probably the easiest
>> move, but we don't actually fix the problem if we use old version of one of
>> the two.
>> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
>> as we do for jetty, etc.
>> 3/ provision spec bundle in the lib folder as we do for activator spec
>> bundle
>>
>> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
>> refer to provided spec feature. With Karaf 4 and the new feature resolver,
>> it would be better to use feature requirements and let the resolver deals
>> with spec bundle.
>>
>> Regards
>> JB
>>
>>
>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>
>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>
>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>>
>>> Currently, both camel and cxf have their features that directly
>>> installing some servicemix-specs bundles. This leads to the problem
>>> mentioned in the above mail thread that installing camel-cxf leads to
>>> installing two versions of servicemix-spec because camel-2.15.2 is
>>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>> using smx-specs 2.4.0.
>>>
>>> I am wondering if we need to define this feature (e.g., feature
>>> stax-api-1.0) outside of camel and cxf and both refer to this external
>>> feature using the appropriate version range e.g. [2.2,3) or we can
>>> locally solve this problem within camel and cxf's feature definitions?
>>>
>>> I would appreciate for your comments.
>>>
>>> regards, aki
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to avoid getting two servicemix-specs versions when installing camel or cxf 's feature
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey,
It does work for things installed by via features, it doesn’t work with bundles enlisted in startup.properties.
Best regards,
Lukasz
> Wiadomość napisana przez Aki Yoshida <el...@gmail.com> w dniu 19 sie 2015, o godz. 15:54:
>
> Hi Lukasz,
> thanks for this info about the override option.
> Is this supported by karaf-3.0.4? It doesn't seem to be working there.
>
> regards, aki
>
> 2015-08-11 9:39 GMT+02:00 Łukasz Dywicki <lu...@code-house.org>:
>> For now you can use overrides mechanism. In etc create file named overrides.properties and place:
>> mvn:org.apache.servicemix.specs/…./2.4.0;version=[2.2.0,3)
>>
>> This will force features service to install version 2.4.0 for anything from range 2.2.0-3.0.
>>
>> Kind regards,
>> Lukasz
>>
>>> Wiadomość napisana przez Aki Yoshida <el...@gmail.com> w dniu 5 sie 2015, o godz. 19:12:
>>>
>>> Hi JB,
>>>
>>> Thanks for the explanation.
>>>
>>> For the current snapshot version of camel (2.16-SNAPSHOT and
>>> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
>>> If the spec features are made available in one of the Karaf's repos as
>>> in approach 2, that will be great. This can avoid this problem for
>>> other combination in the future or with a combination with other
>>> components that also can use this shared features to avoid getting
>>> into this problem.
>>> Will you be providing the spec features as in approach 2?
>>>
>>> Regards, aki
>>>
>>>
>>>
>>> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>> Hi Aki,
>>>>
>>>> We have different ways:
>>>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
>>>> are pretty stable in term of release, I think it's probably the easiest
>>>> move, but we don't actually fix the problem if we use old version of one of
>>>> the two.
>>>> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
>>>> as we do for jetty, etc.
>>>> 3/ provision spec bundle in the lib folder as we do for activator spec
>>>> bundle
>>>>
>>>> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
>>>> refer to provided spec feature. With Karaf 4 and the new feature resolver,
>>>> it would be better to use feature requirements and let the resolver deals
>>>> with spec bundle.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>>>
>>>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>>>
>>>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>>>>
>>>>> Currently, both camel and cxf have their features that directly
>>>>> installing some servicemix-specs bundles. This leads to the problem
>>>>> mentioned in the above mail thread that installing camel-cxf leads to
>>>>> installing two versions of servicemix-spec because camel-2.15.2 is
>>>>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>>>> using smx-specs 2.4.0.
>>>>>
>>>>> I am wondering if we need to define this feature (e.g., feature
>>>>> stax-api-1.0) outside of camel and cxf and both refer to this external
>>>>> feature using the appropriate version range e.g. [2.2,3) or we can
>>>>> locally solve this problem within camel and cxf's feature definitions?
>>>>>
>>>>> I would appreciate for your comments.
>>>>>
>>>>> regards, aki
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
Re: How to avoid getting two servicemix-specs versions when
installing camel or cxf 's feature
Posted by Sobkowiak Krzysztof <kr...@gmail.com>.
Hi
It should work. We use this currently in ServiceMix which is based on Karaf 3.0.4
Regards
Krzysztof
On 19.08.2015 15:54, Aki Yoshida wrote:
> Hi Lukasz,
> thanks for this info about the override option.
> Is this supported by karaf-3.0.4? It doesn't seem to be working there.
>
> regards, aki
>
> 2015-08-11 9:39 GMT+02:00 Łukasz Dywicki <lu...@code-house.org>:
>> For now you can use overrides mechanism. In etc create file named overrides.properties and place:
>> mvn:org.apache.servicemix.specs/…./2.4.0;version=[2.2.0,3)
>>
>> This will force features service to install version 2.4.0 for anything from range 2.2.0-3.0.
>>
>> Kind regards,
>> Lukasz
>>
>>> Wiadomość napisana przez Aki Yoshida <el...@gmail.com> w dniu 5 sie 2015, o godz. 19:12:
>>>
>>> Hi JB,
>>>
>>> Thanks for the explanation.
>>>
>>> For the current snapshot version of camel (2.16-SNAPSHOT and
>>> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
>>> If the spec features are made available in one of the Karaf's repos as
>>> in approach 2, that will be great. This can avoid this problem for
>>> other combination in the future or with a combination with other
>>> components that also can use this shared features to avoid getting
>>> into this problem.
>>> Will you be providing the spec features as in approach 2?
>>>
>>> Regards, aki
>>>
>>>
>>>
>>> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>> Hi Aki,
>>>>
>>>> We have different ways:
>>>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
>>>> are pretty stable in term of release, I think it's probably the easiest
>>>> move, but we don't actually fix the problem if we use old version of one of
>>>> the two.
>>>> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
>>>> as we do for jetty, etc.
>>>> 3/ provision spec bundle in the lib folder as we do for activator spec
>>>> bundle
>>>>
>>>> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
>>>> refer to provided spec feature. With Karaf 4 and the new feature resolver,
>>>> it would be better to use feature requirements and let the resolver deals
>>>> with spec bundle.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>>>
>>>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>>>>
>>>>> Currently, both camel and cxf have their features that directly
>>>>> installing some servicemix-specs bundles. This leads to the problem
>>>>> mentioned in the above mail thread that installing camel-cxf leads to
>>>>> installing two versions of servicemix-spec because camel-2.15.2 is
>>>>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>>>> using smx-specs 2.4.0.
>>>>>
>>>>> I am wondering if we need to define this feature (e.g., feature
>>>>> stax-api-1.0) outside of camel and cxf and both refer to this external
>>>>> feature using the appropriate version range e.g. [2.2,3) or we can
>>>>> locally solve this problem within camel and cxf's feature definitions?
>>>>>
>>>>> I would appreciate for your comments.
>>>>>
>>>>> regards, aki
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
--
Krzysztof Sobkowiak
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member
Apache ServiceMix <http://servicemix.apache.org/> Committer & PMC Member
Senior Solution Architect @ Capgemini SSC <http://www.capgeminisoftware.pl/>
Re: How to avoid getting two servicemix-specs versions when
installing camel or cxf 's feature
Posted by Aki Yoshida <el...@gmail.com>.
Hi Lukasz,
thanks for this info about the override option.
Is this supported by karaf-3.0.4? It doesn't seem to be working there.
regards, aki
2015-08-11 9:39 GMT+02:00 Łukasz Dywicki <lu...@code-house.org>:
> For now you can use overrides mechanism. In etc create file named overrides.properties and place:
> mvn:org.apache.servicemix.specs/…./2.4.0;version=[2.2.0,3)
>
> This will force features service to install version 2.4.0 for anything from range 2.2.0-3.0.
>
> Kind regards,
> Lukasz
>
>> Wiadomość napisana przez Aki Yoshida <el...@gmail.com> w dniu 5 sie 2015, o godz. 19:12:
>>
>> Hi JB,
>>
>> Thanks for the explanation.
>>
>> For the current snapshot version of camel (2.16-SNAPSHOT and
>> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
>> If the spec features are made available in one of the Karaf's repos as
>> in approach 2, that will be great. This can avoid this problem for
>> other combination in the future or with a combination with other
>> components that also can use this shared features to avoid getting
>> into this problem.
>> Will you be providing the spec features as in approach 2?
>>
>> Regards, aki
>>
>>
>>
>> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>> Hi Aki,
>>>
>>> We have different ways:
>>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
>>> are pretty stable in term of release, I think it's probably the easiest
>>> move, but we don't actually fix the problem if we use old version of one of
>>> the two.
>>> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
>>> as we do for jetty, etc.
>>> 3/ provision spec bundle in the lib folder as we do for activator spec
>>> bundle
>>>
>>> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
>>> refer to provided spec feature. With Karaf 4 and the new feature resolver,
>>> it would be better to use feature requirements and let the resolver deals
>>> with spec bundle.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>>
>>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>>
>>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>>>
>>>> Currently, both camel and cxf have their features that directly
>>>> installing some servicemix-specs bundles. This leads to the problem
>>>> mentioned in the above mail thread that installing camel-cxf leads to
>>>> installing two versions of servicemix-spec because camel-2.15.2 is
>>>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>>> using smx-specs 2.4.0.
>>>>
>>>> I am wondering if we need to define this feature (e.g., feature
>>>> stax-api-1.0) outside of camel and cxf and both refer to this external
>>>> feature using the appropriate version range e.g. [2.2,3) or we can
>>>> locally solve this problem within camel and cxf's feature definitions?
>>>>
>>>> I would appreciate for your comments.
>>>>
>>>> regards, aki
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
Re: How to avoid getting two servicemix-specs versions when installing camel or cxf 's feature
Posted by Łukasz Dywicki <lu...@code-house.org>.
For now you can use overrides mechanism. In etc create file named overrides.properties and place:
mvn:org.apache.servicemix.specs/…./2.4.0;version=[2.2.0,3)
This will force features service to install version 2.4.0 for anything from range 2.2.0-3.0.
Kind regards,
Lukasz
> Wiadomość napisana przez Aki Yoshida <el...@gmail.com> w dniu 5 sie 2015, o godz. 19:12:
>
> Hi JB,
>
> Thanks for the explanation.
>
> For the current snapshot version of camel (2.16-SNAPSHOT and
> 2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
> If the spec features are made available in one of the Karaf's repos as
> in approach 2, that will be great. This can avoid this problem for
> other combination in the future or with a combination with other
> components that also can use this shared features to avoid getting
> into this problem.
> Will you be providing the spec features as in approach 2?
>
> Regards, aki
>
>
>
> 2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi Aki,
>>
>> We have different ways:
>> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
>> are pretty stable in term of release, I think it's probably the easiest
>> move, but we don't actually fix the problem if we use old version of one of
>> the two.
>> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
>> as we do for jetty, etc.
>> 3/ provision spec bundle in the lib folder as we do for activator spec
>> bundle
>>
>> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
>> refer to provided spec feature. With Karaf 4 and the new feature resolver,
>> it would be better to use feature requirements and let the resolver deals
>> with spec bundle.
>>
>> Regards
>> JB
>>
>>
>> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>>
>>> Originally, I posted the following mail to dev@camel regarding this issue.
>>>
>>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>>
>>> Currently, both camel and cxf have their features that directly
>>> installing some servicemix-specs bundles. This leads to the problem
>>> mentioned in the above mail thread that installing camel-cxf leads to
>>> installing two versions of servicemix-spec because camel-2.15.2 is
>>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>>> using smx-specs 2.4.0.
>>>
>>> I am wondering if we need to define this feature (e.g., feature
>>> stax-api-1.0) outside of camel and cxf and both refer to this external
>>> feature using the appropriate version range e.g. [2.2,3) or we can
>>> locally solve this problem within camel and cxf's feature definitions?
>>>
>>> I would appreciate for your comments.
>>>
>>> regards, aki
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
Re: How to avoid getting two servicemix-specs versions when
installing camel or cxf 's feature
Posted by Aki Yoshida <el...@gmail.com>.
Hi JB,
Thanks for the explanation.
For the current snapshot version of camel (2.16-SNAPSHOT and
2.15.3-SNAPSHOT), we used approach 1 to solve this problem for now.
If the spec features are made available in one of the Karaf's repos as
in approach 2, that will be great. This can avoid this problem for
other combination in the future or with a combination with other
components that also can use this shared features to avoid getting
into this problem.
Will you be providing the spec features as in approach 2?
Regards, aki
2015-08-05 17:28 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi Aki,
>
> We have different ways:
> 1/ we "align" CXF and Camel to the same spec bundle version. As spec bundles
> are pretty stable in term of release, I think it's probably the easiest
> move, but we don't actually fix the problem if we use old version of one of
> the two.
> 2/ remove spec from CXF and Camel and put a spec feature directly in Karaf,
> as we do for jetty, etc.
> 3/ provision spec bundle in the lib folder as we do for activator spec
> bundle
>
> Probably 2 would make sense. Anyway, we will have to update CXF and Camel to
> refer to provided spec feature. With Karaf 4 and the new feature resolver,
> it would be better to use feature requirements and let the resolver deals
> with spec bundle.
>
> Regards
> JB
>
>
> On 08/05/2015 11:38 AM, Aki Yoshida wrote:
>>
>> Originally, I posted the following mail to dev@camel regarding this issue.
>>
>> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>>
>> Currently, both camel and cxf have their features that directly
>> installing some servicemix-specs bundles. This leads to the problem
>> mentioned in the above mail thread that installing camel-cxf leads to
>> installing two versions of servicemix-spec because camel-2.15.2 is
>> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
>> using smx-specs 2.4.0.
>>
>> I am wondering if we need to define this feature (e.g., feature
>> stax-api-1.0) outside of camel and cxf and both refer to this external
>> feature using the appropriate version range e.g. [2.2,3) or we can
>> locally solve this problem within camel and cxf's feature definitions?
>>
>> I would appreciate for your comments.
>>
>> regards, aki
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: How to avoid getting two servicemix-specs versions when installing
camel or cxf 's feature
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Aki,
We have different ways:
1/ we "align" CXF and Camel to the same spec bundle version. As spec
bundles are pretty stable in term of release, I think it's probably the
easiest move, but we don't actually fix the problem if we use old
version of one of the two.
2/ remove spec from CXF and Camel and put a spec feature directly in
Karaf, as we do for jetty, etc.
3/ provision spec bundle in the lib folder as we do for activator spec
bundle
Probably 2 would make sense. Anyway, we will have to update CXF and
Camel to refer to provided spec feature. With Karaf 4 and the new
feature resolver, it would be better to use feature requirements and let
the resolver deals with spec bundle.
Regards
JB
On 08/05/2015 11:38 AM, Aki Yoshida wrote:
> Originally, I posted the following mail to dev@camel regarding this issue.
> http://camel.465427.n5.nabble.com/Installing-camel-cxf-2-15-2-feature-leads-to-two-versions-of-ServiceMix-Stax-API-bundles-installed-td5769830.html
>
> Currently, both camel and cxf have their features that directly
> installing some servicemix-specs bundles. This leads to the problem
> mentioned in the above mail thread that installing camel-cxf leads to
> installing two versions of servicemix-spec because camel-2.15.2 is
> using smx-specs 2.2.0 while cxf-3.0.4 referred in camel-2.15.2 is
> using smx-specs 2.4.0.
>
> I am wondering if we need to define this feature (e.g., feature
> stax-api-1.0) outside of camel and cxf and both refer to this external
> feature using the appropriate version range e.g. [2.2,3) or we can
> locally solve this problem within camel and cxf's feature definitions?
>
> I would appreciate for your comments.
>
> regards, aki
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com