Sorry to wind this back a little, but there were a couple of questions from Tom which got skipped over.
I'm afraid that when it comes to shells there isn't a standard. There was an RFC created a long time ago, which roughly represented the work that is now Gogo. There was a decision at the time that there wasn't a need for a standard, this decision could be revisited, particularly if someone wants to drive the work through the Alliance. As for the following question: >> Originally I thought that Karaf was the "enterprise version of felix". This >> doesn't seem to be the case? Karaf and Felix may both be hosted at Apache, but Karaf is a totally separate project from Felix with a very different ethos. Karaf does not implement an OSGi framework, or OSGi standards, but builds a server based on OSGi components from a variety of places. Karaf is flexible, but ultimately opinionated about libraries and dictates a number of high level choices. Felix works hard to allow you to use implementations from anywhere with the standalone components they produce. Karaf is also prepared to invent concepts (e.g. features and kar files) and not contribute them back to OSGi, leaving them as proprietary extensions. This even happens when OSGi standards do exist (or are nearly final). Karaf also promotes non standard (and some non Apache) programming model extensions. While this does, by some measures, make Karaf a "bad" OSGi citizen, it is also one of the reasons why Karaf is so successful, and helps to drive OSGi adoption (a very good thing for OSGi). By being opinionated Karaf can be simpler for new users, even if it provides a more limited view of what your OSGi options are. The Felix framework, on the other hand, lets you make all the decisions, but also requires you to make all the decisions! In summary I would describe Karaf as an Open Source OSGi server runtime, where Felix is more like a base operating system. Tim Sent from my iPhone > On 22 Jul 2017, at 06:44, Christian Schneider <ch...@die-schneider.net> wrote: > > That sounds interesting. Can you point us to the code where those commands > are implemented and where the completion is defined? > I know there is the completion support that you can define in the shell init > script but I think this is difficult to maintain this way. > > Is it now possible to somehow define the completion for gogo commands per > bundle or even by annotations directly on the class? > > Christian > > 2017-07-21 16:57 GMT+02:00 Guillaume Nodet <gno...@apache.org>: >> If you look at Karaf >= 4.1.x, a bunch of commands are not coming from Karaf >> anymore, but from Gogo or JLine. I moved them when working on the gogo / >> jline3 integration. The main point that was blocking imho is that they did >> not have completion support. With the new fully scripted completion system >> from gogo-jline, gogo commands can have full completion, so I don't see any >> blocking points anymore. It's just about tracking commands and registering >> them in the karaf shell. >> >> 2017-07-21 15:27 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: >>>> On 21.07.2017 12:27, t...@quarendon.net wrote: >>>> Yes, but what's the actual situation from a standards point of view? >>>> Is a shell defined by a standard at all? OSGi enroute seems to require a >>>> gogo shell and appears to rely on felix gogo shell command framework. >>>> Is it just that Karaf happens to ship a shell that happens to be based on >>>> the felix gogo shell (or perhaps not, but stack traces seem to suggest >>>> so), but that basically if I want to implement a shell command I have to >>>> implement it differently for each shell type? >>>> >>>> That seems a poor situation and leaves me with having to implement one >>>> command implementation to be used in the development environment and one >>>> that is used in the karaf deployment. >>>> >>>> Originally I thought that Karaf was the "enterprise version of felix". >>>> This doesn't seem to be the case? >>>> >>>> There *could* be a really powerful environment and ecosystem here, if it >>>> was all a *little* bit less fragmented :-) >>> I fully agree that we need to work towards more common approaches. The OSGi >>> ecosystem is too small to afford being fragmented like this. >>> We all have the chance and duty to work on improving this though. >>> >>> Christian >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com
