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 ?
