Jean-Baptiste,

Rather than committing ourselves to 2 releases close to each other
right now, I would see how far we get with our own refactorings and
build/release process optimizations.  If CXF 2.4.0 and the matching
Camel release have been released by then, I would just do a single
release with those bits updated instead of doing another backlevel
release first.  However, if we manage to beat the CXF/Camel teams in
speed, I'll gladly help doing both of these releases.


Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Mon, Apr 4, 2011 at 7:47 AM, Jean-Baptiste Onofré <[email protected]> wrote:
> Hi Gert,
>
> Yes, Camel should be "aligned" to use CXF 2.4.0.
>
> For now, I'm agree to stay with CXF 2.3.x to complete the build.
> However, when CXF 2.4.0 and Camel 2.7.1 will be released, I think it makes
> sense to move quickly on these releases.
>
> Why not:
> - SMX 4.4.0 on CXF 2.3.x and Camel 2.7.0
> - SMX 4.4.1 on CXF 2.4.0 and Camel 2.7.1
> ?
>
> WDYT ?
>
> Regards
> JB
>
> On 04/03/2011 09:55 PM, Gert Vanthienen wrote:
>>
>> L.S.,
>>
>>
>> If we pick up CXF 2.4.0, we'll have to wait for another Camel release
>> as well because the current Camel CXF uses CXF 2.3.2 (and uses OSGi
>> import range [2.3.2,2.4) to refer to the CXF packages). I'm not
>> against picking up CXF 2.4.0, quite on the contrary, so if waiting a
>> few weeks can give us a new Camel and CXF release to include, that
>> would be really good.
>>
>> However, in the meanwhile, I would suggest we focus on achieving our
>> primary goal, which is to make sure that we streamline our build and
>> release process as much as possible, and as soon as we have more
>> information about when the CXF and matching Camel release will be
>> available, we can make a more informed decision.
>>
>> Could you add the information or a link to the relevant Camel issue to
>> the SMX4-782 JIRA issue (I assume that's the one that Daniele is
>> referring to) as well to ensure the entire team can follow along
>> there?
>>
>>
>> Thanks,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Sun, Apr 3, 2011 at 8:59 PM, Jean-Baptiste Onofré<[email protected]>
>>  wrote:
>>>
>>> Hi,
>>>
>>> As already discussed :), your issue is relative to Camel.
>>>
>>> I'm preparing a test case to try to reproduce the issue and check if it's
>>> already present on 4.4-SNAPSHOT.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/03/2011 08:26 PM, geaaru wrote:
>>>>
>>>> Hi at all,
>>>>
>>>> I'm not a smx developer, but an user and I hope that my comment will
>>>> help
>>>> decision for next release.
>>>>
>>>> I'm currently used yet an old smx version create from a commit of the
>>>> smx-4.3.0-snapshot with module 2010.10 because new smx-4.3.0 is it very
>>>> unstable at least in my case where i use a lot camel and camel-jbi
>>>> component.
>>>>
>>>> Currently it isn't possible do:
>>>> - a restart of a sa with servimix-camel that use from("jbi:endpoint...")
>>>> - deploy a blueprint camel route with jbi destination (.to("jbi...")) or
>>>> jbi endpoint.
>>>>
>>>> I don't known if that components will be maintained but if yes are in
>>>> this
>>>> moment unusable and i think that before next release this bug must be
>>>> closed.
>>>>
>>>> Thanks for read my messagge.
>>>>
>>>> Good work at all.
>>>>
>>>> Geaaru
>>>> ----- Original message -----
>>>>>
>>>>> Hi all,
>>>>>
>>>>> The CXF team has made a lot of improvements around OSGi and especially
>>>>> Blueprint.
>>>>>
>>>>> They plan to release CXF 2.4.0 soon (in the following weeks).
>>>>>
>>>>> I think it could have sense to use CXF 2.4.0 for ServiceMix 4.4.0.
>>>>>
>>>>> It means that ServiceMix 4.4.0 will ship:
>>>>> - Karaf 2.2.0 (maybe 2.2.1 at least to have a fix on the zip archive,
>>>>> even if we can fix it in ServiceMix itself)
>>>>> - ActiveMQ 5.5.0 (already done)
>>>>> - Camel 2.7.0 (already done)
>>>>> - CXF 2.4.0
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>
>>>
>

Reply via email to