I thought about that, but then, the bundles would be tied to Karaf while
the goal is to support commands from projects which are not related to
karaf.  Else, we could just force them to use our own command api if they
want to support Karaf ;-)

Also remember that scripting offers very nice additional features : it's
dynamic.  A static completion system would not be able to offer the same
level, so you'd have to offer an api, and then... well, it's not
independent anymore, so you've lost the benefit.

The fact that the scripts are external it not necessarily a problem.
That's the way your unix shell completion works btw ;-)

2016-10-19 13:14 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:

> Not sure if the script approach is good for the long run.
>
> What we could do with it though is to provide a script in a magic location
> in each bundle.
> The shell could then dynamically add and remove the scripts as the bundles
> are started / stopped.
> Does that make sense ?
>
> For the long run I think we could have a service that provides this
> information. Kind of a command metadata service.
> A bundle could either offer such a service manually or it could be created
> by an extender from annotation data.
> Such a solution could then also cover the plain karaf commands.
>
> Christian
>
> On 12.10.2016 17:57, Guillaume Nodet wrote:
>
>> I'm working on trying to nicely integrate gogo commands.
>> The new gogo-jline bundle has a very nice way to allow external
>> configuration for command completion. For example, one need to execute the
>> script at https://gist.github.com/gnodet/18de68d57fc959efb7f9e4766415ff5e
>> to add full completion to the Karaf shell once you have the scr bundle
>> installed (it always provides gogo commands).  Other examples are
>> available
>> at
>> https://github.com/apache/felix/blob/trunk/gogo/jline/src/
>> main/resources/gosh_profile
>>
>> The question is : how to provide such a script.
>> One possibility would be to have a dedicated folder such as etc/scripts/
>> where all scripts would be loaded when a session is started. We could then
>> reference those files in features so that they are copied when features
>> are
>> installed.
>> This would allow leveraging the <configfile> feature xml element.
>>
>> Do you guys have better ideas ?
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Reply via email to