Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.213.173 as permitted sender)
Message-ID: <4FA0A916.5090603@gmail.com>
Date: Wed, 02 May 2012 11:25:10 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: Problem with Camel commands and and Karaf 3
References: <4F9E58D6.7060903@die-schneider.net>
 <4F9E7C37.9090503@nanthrax.net>
In-Reply-To: <4F9E7C37.9090503@nanthrax.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

It could easy for us to break the dependency of karaf 2.2.x when the 
karaf 3.x is out.
I don't think the define gogo and karaf import as optional can make the 
camel command
 support the karaf 2.2.x and karaf 3.x at the same time, if the user 
still want to use the camel command.

On Mon Apr 30 19:49:11 2012, Jean-Baptiste Onofré wrote:
> Hi,
>
> For the others, the incompatible stuff are:
> - the version range in the OSGi import statement (it should be
> something like [2.2,4) instead of [2.2,3)
> - in Karaf 3.0 (trunk), we moved some packages from gogo to karaf, and
> so the import statement should be improved
>
> On the other hand, in Karaf 3.0, we introduce shell namespace 1.1
> instead of 1.0 which is better for commands definition.
>
> I'm not very in favour of extracting the commands from the camel-core
> feature. However, it can make sense:
> - if an user doesn't want to provide shell commands in its Karaf
> runtime (for instance, to force management of routes via JMX or pro
> grammatically)
> - to fix the current issue
>
> However, I see different solutions:
> - once Karaf 3.0 is out, why not to decide the "break" the Karaf 2.2
> in Camel or CXF. It's what we already did. For instance, with Karaf <
> 2.2.6, you can't install latest CXF version (due to a missing feature
> provided by Karaf). So we "forced" users to upgrade to a new Karaf
> 2.2.x version. It's right that it's a "minor" ugprade comparing to
> Karaf 3.0
> - we can stay with shell 1.0.0 namespace, upgrade the version range to
> [2.2,4) and define gogo and karaf import as optional. Like this we can
> support both Karaf 2.2 and Karaf 3.0 version in the same CXF/Camel
> version.
> - provide a "transition" package in Karaf 3.0 (gogo package) which use
> the Karaf one.
>
> Regards
> JB
>
> On 04/30/2012 11:18 AM, Christian Schneider wrote:
>> Hi all,
>>
>> we provide some camel commands for karaf in our distro. With Karaf 3
>> there are some incompatible changes in the command API. So currently
>> camel does not install on Karaf 3.
>> I will try to work out a solution for the commands to ideally make them
>> compatible.
>>
>> For the moment though I propose we remove the command bundle from the
>> camel-core feature and move it to a command that can be installed
>> spearately. So Camel can already be used and tested on Karaf 3. Is this
>> ok? If yes for what versions of camel should I do this change? I think
>> 2.9.x and trunk could make sense.
>>
>> Christian
>>
>


--
Willem
----------------------------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
         http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang