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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
