You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@apache.org> on 2014/02/12 11:28:52 UTC
[DISCUSS] Simplify the link between actions and completers
When writing a command, completers have to be wired in blueprint in a not
very easy to use way.
For example:
<command name="config/propset">
<action class="org.apache.karaf.shell.config.PropSetCommand">
<property name="storage" value="${storage}" />
</action>
<completers>
<ref component-id="configPropertyCompleter" />
<null/>
</completers>
<optional-completers>
<entry key="-p" value-ref="configCompleter"/>
</optional-completers>
</command>
In addition, completers are often shared between commands.
I'm thinking about simplifying a bit things by:
* adding a @Completer annotation which has a Class argument which would
be used
on fields annotated with @Argument or @Option
* if such a field is present, try to find the completer in the OSGi
registry
The result would look like:
<command>
<action class="org.apache.karaf.config.command.PropSetCommand">
<property name="configRepository" ref="configRepo"/>
</action>
</command>
@Argument(index = 0, name = "property", description = "The name of the
property to set", required = true, multiValued = false)
@Completer(ConfigurationPropertyCompleter.class)
String prop;
@Option(name = "-p", aliases = "--pid", description = "The
configuration pid", required = false, multiValued = false)
@Completer(ConfigurationCompleter.class)
protected String pid;
Of course, the requirement is to also export the two completers as services.
I think completers should be hidden when listing services, along with
commands.
Overall, I think it would make things cleaner, as separating the completers
from the arguments/options definition has no value, especially when the
completer list has to be ordered and the optional completers refer to the
option name...
Thoughts ?
Re: [DISCUSS] Simplify the link between actions and completers
Posted by Ioannis Canellos <io...@gmail.com>.
I like it!
Since we are already using annotations it makes sense to configure all
of the commands parameters via annotation. Using both annotations and
XML is a bit icky.
I quite a few places before (e.g. jclouds-karaf) I've had cases with
reusable completes and using the OSGi service registry made a lot of
sense and worked pretty well.
Also, this idea will make things so much easier to anyone that wants
to hack non blueprint commands (e.g. scr based).
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: [DISCUSS] Simplify the link between actions and completers
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Very good idea Guillaume.
+1 for that.
Regards
JB
On 02/12/2014 11:28 AM, Guillaume Nodet wrote:
> When writing a command, completers have to be wired in blueprint in a not
> very easy to use way.
> For example:
>
> <command name="config/propset">
> <action class="org.apache.karaf.shell.config.PropSetCommand">
> <property name="storage" value="${storage}" />
> </action>
> <completers>
> <ref component-id="configPropertyCompleter" />
> <null/>
> </completers>
> <optional-completers>
> <entry key="-p" value-ref="configCompleter"/>
> </optional-completers>
> </command>
>
> In addition, completers are often shared between commands.
>
> I'm thinking about simplifying a bit things by:
> * adding a @Completer annotation which has a Class argument which would
> be used
> on fields annotated with @Argument or @Option
> * if such a field is present, try to find the completer in the OSGi
> registry
>
> The result would look like:
>
> <command>
> <action class="org.apache.karaf.config.command.PropSetCommand">
> <property name="configRepository" ref="configRepo"/>
> </action>
> </command>
>
> @Argument(index = 0, name = "property", description = "The name of the
> property to set", required = true, multiValued = false)
> @Completer(ConfigurationPropertyCompleter.class)
> String prop;
>
> @Option(name = "-p", aliases = "--pid", description = "The
> configuration pid", required = false, multiValued = false)
> @Completer(ConfigurationCompleter.class)
> protected String pid;
>
> Of course, the requirement is to also export the two completers as services.
> I think completers should be hidden when listing services, along with
> commands.
>
> Overall, I think it would make things cleaner, as separating the completers
> from the arguments/options definition has no value, especially when the
> completer list has to be ordered and the optional completers refer to the
> option name...
>
> Thoughts ?
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] Simplify the link between actions and completers
Posted by Freeman Fang <fr...@gmail.com>.
This is nice!
+1
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On 2014-2-12, at 下午6:28, Guillaume Nodet wrote:
> When writing a command, completers have to be wired in blueprint in a not
> very easy to use way.
> For example:
>
> <command name="config/propset">
> <action class="org.apache.karaf.shell.config.PropSetCommand">
> <property name="storage" value="${storage}" />
> </action>
> <completers>
> <ref component-id="configPropertyCompleter" />
> <null/>
> </completers>
> <optional-completers>
> <entry key="-p" value-ref="configCompleter"/>
> </optional-completers>
> </command>
>
> In addition, completers are often shared between commands.
>
> I'm thinking about simplifying a bit things by:
> * adding a @Completer annotation which has a Class argument which would
> be used
> on fields annotated with @Argument or @Option
> * if such a field is present, try to find the completer in the OSGi
> registry
>
> The result would look like:
>
> <command>
> <action class="org.apache.karaf.config.command.PropSetCommand">
> <property name="configRepository" ref="configRepo"/>
> </action>
> </command>
>
> @Argument(index = 0, name = "property", description = "The name of the
> property to set", required = true, multiValued = false)
> @Completer(ConfigurationPropertyCompleter.class)
> String prop;
>
> @Option(name = "-p", aliases = "--pid", description = "The
> configuration pid", required = false, multiValued = false)
> @Completer(ConfigurationCompleter.class)
> protected String pid;
>
> Of course, the requirement is to also export the two completers as services.
> I think completers should be hidden when listing services, along with
> commands.
>
> Overall, I think it would make things cleaner, as separating the completers
> from the arguments/options definition has no value, especially when the
> completer list has to be ordered and the optional completers refer to the
> option name...
>
> Thoughts ?