You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Timothy Ward (JIRA)" <ji...@apache.org> on 2018/12/21 15:58:00 UTC

[jira] [Comment Edited] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved

    [ https://issues.apache.org/jira/browse/FELIX-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726854#comment-16726854 ] 

Timothy Ward edited comment on FELIX-5970 at 12/21/18 3:57 PM:
---------------------------------------------------------------

{quote}I've implemented it slightly differently. There's a gogo specific namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo _love triangle_ (runtime, shell impl, command.)
{quote}
 

I'm not sure why this approach was taken. Gogo commands use a whiteboard model and so as someone contributing a Gogo command I would expect to use the osgi.implementation namespace to pull in a whiteboard implementation. 

I can understand that if you want to start doing *deep shell* work with live input or changing the colour of the text then you need something more akin to the model that you have defined, but what if I just want to provide a command that could be used with vanilla Gogo or JLine Gogo?

 

For something nicely usable I would expect to see the following annotations:

{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command", version=1.0.0)}}

{{public @interface RequireCommandWhiteboard \{ }}}

 

{{@RequireCommandWhiteboard}}

{{@ComponentPropertyType}}

{{public @interface GogoCommand {}}

{{    public static final String _PREFIX = "osgi.command.";}}{{    }}

{{    public String scope();}}

{{    public String[] function();}}

{{}}}

 

These would then be used as follows:

 

{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}

{{@Component(service=MyCommand.class)}}

{{public class MyCommand {}}

{{    public String bar() \{ ... }}}

{{    public String baz(int n) \{ ... }}}

{{}}}


was (Author: timothyjward):
{quote}I've implemented it slightly differently. There's a gogo specific namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo _love triangle_ (runtime, shell impl, command.)
{quote}
 

I'm not sure why this approach was taken. Gogo commands use a whiteboard model and so as someone contributing a Gogo command I would expect to use the osgi.implementation namespace to pull in a whiteboard implementation. 

I can understand that if you want to start doing *deep shell* work with live input or changing the colour of the text then you need something more akin to the model that you have defined, but what if I just want to provide a command that could be used with vanilla Gogo or JLine Gogo?

 

For something nicely usable I would expect to see the following annotations:

{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command", version=1.0.0)}}

{{public @interface RequireCommandWhiteboard \{ }}}

 

{{@RequireCommandWhiteboard}}

{{@ComponentPropertyType}}

{{public @interface GogoCommand {}}{{    }}

{{    public static final String _PREFIX = "osgi.command.";}}{{    }}

{{    public String scope();}}{{    }}

{{    public String[] function();}}

{{}}}

 

These would then be used as follows:

 

{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}

{{@Component(service=MyCommand.class)}}

{{public class MyCommand {}}

{{    public String bar() \{ ... }}}

{{    public String baz(int n) \{ ... }}}

{{}}}

> Add requirement & capabilities model so gogo can be resolved
> ------------------------------------------------------------
>
>                 Key: FELIX-5970
>                 URL: https://issues.apache.org/jira/browse/FELIX-5970
>             Project: Felix
>          Issue Type: Improvement
>          Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>            Reporter: Raymond Augé
>            Assignee: Raymond Augé
>            Priority: Major
>             Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2, gogo.shell-1.1.2, gogo.jline-1.1.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)