Basically, OsgiCommandSupport is "just" a wrapper on top of the Gogo
action. But, it brings convenience for loading/unloading the related
OSGi services.
However, in "previous" version, we ship our own version of Gogo, with
some modification. That's why using the OsgiCommandSupport, you are sure
to use the version of Gogo that we embed in Karaf.
In new Karaf version (especially in the future Karaf 4), it's largely
cleaner.
Regards
JB
On 05/20/2014 03:58 PM, Giovanni Meo wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
