Hi JB,
thanks for the answer, but i'm just curious to understand what we loose with
gogo way. We are in an environment where karaf is being rolled in, but already
have gogo shell.
Thanks,
Giovanni
On 20-May-14 15:23, Jean-Baptiste Onofré wrote:
> Hi Giovanni,
>
> my advice is to still extend OsgiCommandSupport up to Karaf 3.
> Like this, you are sure that it works fine (with all the related like
> completion, help, etc).
>
> In Karaf 4, we introduced a new API.
>
> Regards
> JB
>
> On 05/19/2014 02:57 PM, Giovanni Meo wrote:
>> Hi Karaf-users,
>>
>> I have a newbie karaf CLI question. I have learned that karaf CLIs can be
>> defined in two ways:
>>
>> 1) By extending the class OsgiCommandSupport and publishing in the OSGi
>> service
>> registry
>> 2) By using a POJO and registering it in the OSGi service registry with
>> osgi.command and osgi.scope properties attached (GOGO shell way)
>>
>> now in the project i work on we already have some CLI using #2 and many older
>> CLI using the Equinox way (implementing CommandProvider). We want to migrate
>> those old CLIs to be compatible with Karaf, but given still we are not yet
>> fully
>> on Karaf but we do have GOGO shell, i have been thinking to use the GOGO
>> shell
>> way (approach #2).
>> Now i have been asking around and folks suggest to go via #1 directly, but
>> given
>> we are not yet fully on Karaf #1 would break our current containers, unless
>> we
>> create a level of indirection.
>> Now the question i ask is, what do we loose in Karaf if we go the approach #2
>> and what makes (technically) approach #1 the preferred one?
>>
>> Thanks in advance for any help you can provide,
>> Giovanni
>>
>
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
