Writing commands for karaf shell.

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Writing commands for karaf shell.

tomq42
There was a thread recently related to this, but I have a different question.

I'm confused about the shell situation, and what is "standard" and what is not.

I have naively written some commands for the felix gogo shell. We develop using bndtools (obviously) and use the OSGI enRoute templates, and that's all set up to use the apache felix gogo shell implementation and related bundles.
The commands I have written make use of what I *thought* were standard features such as org.apache.felix.service.command.Descriptor and org.apache.felix.service.command.Parameter parameter annotations and the org.apache.felix.service.command.CommandSession interface (though the fact that they are in the felix namespace did confuse me). The commands are registered using the osgi.enroute.debug.api.Debug constants.

If I try and run these inside Karaf it clearly understands that the command is there, so the registration is working, it's just it obviously doesn't understand the Parameter annotations and CommandSession interface, so can't call it ("cannot cooerce ..." error).

From the examples, Karaf has its own, non standard way of writing command extensions, it doesn't seem to use the osgi.enroute.debug.api.Debug constants.

So can someone clarify the situation?
Is *anything* actually standard at all? I can't find any reference in the OSGi specs to a shell (but then I'm probably not looking for the right thing), so perhaps not.
Does karaf use the apache felix gogo shell implementation (I thought it did)?
If so, should it be able to understand things like the Parameter annotation, and CommandSession?

Or should this all work, but it's just that I'm missing some vital bundle in my installation?

Thanks.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

jbonofre
From a karaf perspective, the standard is to use karaf commands/annotations. Gogo commands support is just for compatibility (as the features are limited). When gogo commands will improve and provide the same the same features, it could change.

Others may have different standpoint but there's mine ;)

Regards
JB
On Jul 21, 2017, at 11:54, [hidden email] wrote:
There was a thread recently related to this, but I have a different question.

I'm confused about the shell situation, and what is "standard" and what is not.

I have naively written some commands for the felix gogo shell. We develop using bndtools (obviously) and use the OSGI enRoute templates, and that's all set up to use the apache felix gogo shell implementation and related bundles.
The commands I have written make use of what I *thought* were standard features such as org.apache.felix.service.command.Descriptor and org.apache.felix.service.command.Parameter parameter annotations and the org.apache.felix.service.command.CommandSession interface (though the fact that they are in the felix namespace did confuse me). The commands are registered using the osgi.enroute.debug.api.Debug constants.

If I try and run these inside Karaf it clearly understands that the command is there, so the registration is working, it's just it obviously doesn't understand the Parameter annotations and CommandSession interface, so can't call it ("cannot cooerce ..." error).

From the examples, Karaf has its own, non standard way of writing command extensions, it doesn't seem to use the osgi.enroute.debug.api.Debug constants.

So can someone clarify the situation?
Is *anything* actually standard at all? I can't find any reference in the OSGi specs to a shell (but then I'm probably not looking for the right thing), so perhaps not.
Does karaf use the apache felix gogo shell implementation (I thought it did)?
If so, should it be able to understand things like the Parameter annotation, and CommandSession?

Or should this all work, but it's just that I'm missing some vital bundle in my installation?

Thanks.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

tomq42
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 :-)

> On 21 July 2017 at 11:01 Jean-Baptiste Onofré <[hidden email]> wrote:
>
>
> From a karaf perspective, the standard is to use karaf commands/annotations. Gogo commands support is just for compatibility (as the features are limited). When gogo commands will improve and provide the same the same features, it could change.
>
> Others may have different standpoint but there's mine ;)
>
> Regards
> JB
>
> On Jul 21, 2017, 11:54, at 11:54, [hidden email] wrote:
> >There was a thread recently related to this, but I have a different
> >question.
> >
> >I'm confused about the shell situation, and what is "standard" and what
> >is not.
> >
> >I have naively written some commands for the felix gogo shell. We
> >develop using bndtools (obviously) and use the OSGI enRoute templates,
> >and that's all set up to use the apache felix gogo shell implementation
> >and related bundles.
> >The commands I have written make use of what I *thought* were standard
> >features such as org.apache.felix.service.command.Descriptor and
> >org.apache.felix.service.command.Parameter parameter annotations and
> >the org.apache.felix.service.command.CommandSession interface (though
> >the fact that they are in the felix namespace did confuse me). The
> >commands are registered using the osgi.enroute.debug.api.Debug
> >constants.
> >
> >If I try and run these inside Karaf it clearly understands that the
> >command is there, so the registration is working, it's just it
> >obviously doesn't understand the Parameter annotations and
> >CommandSession interface, so can't call it ("cannot cooerce ..."
> >error).
> >
> >From the examples, Karaf has its own, non standard way of writing
> >command extensions, it doesn't seem to use the
> >osgi.enroute.debug.api.Debug constants.
> >
> >So can someone clarify the situation?
> >Is *anything* actually standard at all? I can't find any reference in
> >the OSGi specs to a shell (but then I'm probably not looking for the
> >right thing), so perhaps not.
> >Does karaf use the apache felix gogo shell implementation (I thought it
> >did)?
> >If so, should it be able to understand things like the Parameter
> >annotation, and CommandSession?
> >
> >Or should this all work, but it's just that I'm missing some vital
> >bundle in my installation?
> >
> >Thanks.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

cschneider
On 21.07.2017 12:27, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

Guillaume Nodet-2
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

tomq42
> 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.

I'm sorry, but I don't really understand what you're saying. You're talking about impediments to making changes to Karaf? Or how I go about writing commands?
Sorry, just not following.

Fundamentally, should commands that I write using apache felix gogo command features such as the Parameter and Description annotations, and the CommandService interface work? Or if I want to do something other than a simple "hello world", do I need to work out how to use the karaf shell from within bndtools so that I can write commands using the Karaf command framework?

Thanks.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

Guillaume Nodet-2
Right now, stick with the Karaf annotations if you want to deploy your commands in Karaf.  It works and it's supported.  
My previous comment was more a reply to Christian about what needs to be done to support gogo commands in the future.

2017-07-21 17:27 GMT+02:00 <[hidden email]>:
> 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.

I'm sorry, but I don't really understand what you're saying. You're talking about impediments to making changes to Karaf? Or how I go about writing commands?
Sorry, just not following.

Fundamentally, should commands that I write using apache felix gogo command features such as the Parameter and Description annotations, and the CommandService interface work? Or if I want to do something other than a simple "hello world", do I need to work out how to use the karaf shell from within bndtools so that I can write commands using the Karaf command framework?

Thanks.



--
------------------------
Guillaume Nodet

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

cschneider
In reply to this post by Guillaume Nodet-2
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 <[hidden email]>:
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

Timothy Ward
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

jbonofre
That's what I said: there is not generic standard and the standard in Karaf is the Karaf commands.

My €0.1

Regards
JB
On Jul 22, 2017, at 12:16, Tim Ward <[hidden email]> wrote:
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 < [hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

Guillaume Nodet-2
In reply to this post by Timothy Ward


2017-07-22 12:16 GMT+02:00 Tim Ward <[hidden email]>:
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.

May I point out that there's no such thing like "contributing back to OSGi".  The OSGi Alliance is not an open source organization, where people are free to contribute.  It's a paying membership organization, so that's very opposite to the ASF way of doing things.  The only thing that can exist is that some OSGi Alliance members contribute to an OSS project and also work in the OSGi Alliance on related things, but there's no way for an open source project to contribute anything per se.  It happens that most Karaf developpers are not OSGi Alliance members, so they don't have a saying to what happens there...
 

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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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



--
------------------------
Guillaume Nodet

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Writing commands for karaf shell.

Guillaume Nodet-2
In reply to this post by cschneider


2017-07-22 7:44 GMT+02:00 Christian Schneider <[hidden email]>:
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?

No, I was referring to the scripting way of defining completion.  Given a gogo command is only defined by implementing the Function interface, the completion mechanism has to be defined externally.
 

Christian

2017-07-21 16:57 GMT+02:00 Guillaume Nodet <[hidden email]>:
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 <[hidden email]>:
On <a href="tel:21.07.2017%2012" value="+12107201712" target="_blank">21.07.2017 12:27, [hidden email] 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



--
------------------------
Guillaume Nodet

Loading...