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 ?

Reply via email to