felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [gogo] Advanced commands / console
Date Thu, 02 Jul 2009 13:53:42 GMT
On 7/2/09 2:24 AM, Guillaume Nodet wrote:
> For Karaf, I've been working on a prototype to be able to support more
> powerful commands in gogo.
> The problem with the current way (i.e. one function == one method) is
> that it's quite difficult to
>    * display help for a command
>    * have optional arguments
> So what I've done, and this would also benefit Karaf, is based on what
> gshell is doing for commands.
> It's based on the following interfaces:
>
> public interface Action
> {
>      Object execute(CommandSession session) throws Exception;
> }
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE})
> public @interface Command
> {
>      String scope();
>
>      String name();
>
>      String description() default "";
> }
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.FIELD, ElementType.METHOD})
> public @interface Argument
> {
>      String name() default "VAL";
>
>      String description() default "";
>
>      boolean required() default false;
>
>      int index() default 0;
>
>      boolean multiValued() default false;
> }
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.FIELD, ElementType.METHOD})
> public @interface Option
> {
>      String name();
>
>      String[] aliases() default {};
>
>      String description() default "";
>
>      boolean required() default false;
>
>      boolean multiValued() default false;
>
> }
>
>
> So a given command would look like:
>
> @Command(scope = "my", name = "action")
> public class MyAction implements Action {
>
>      @Option(name = "-s", aliases = { "--start" })
>      boolean start;
>
>     @Argument(name = "ids", required = true, multivalued = true)
>     List<Integer>  ids;
>
>     public Object execute(CommandSession session) {
>         ...
>     }
> }
>
>
> This action has to be wrapped inside a command (implementing the
> Function interface) and which will be able to create a new instance of
> the action, parse the arguments, populate it, and call it.
> In addition the wrapper will detect the use of "-h" or "--help"
> arguments and compute / display the help on the console if requested.
>
> Curerntly, what I've done is leveraging blueprint, so I have a custom
> namespace (same as we had in karaf/gshell)
>
>      <command-bundle xmlns="http://felix.apache.org/karaf/xmlns/gshell/v1.0.0">
>          <command name="osgi/list">
>              <action class="org.apache.felix.karaf.gshell.osgi.ListBundles">
>                  <property name="blueprintListener" ref="blueprintListener"/>
>              </action>
>          </command>
>      </command-bundle>
>
> This will create a command and register it in the OSGi registry so
> that it will be available in the shell.
>    

The above sounds interesting, but I would hope that using Blueprint 
would be optional.

Of course, to some degree, if Gogo becomes the reference impl for the 
OSGi Shell, we run a risk of creating non-spec'ed features that could 
confuse people. However, right now we have an opportunity to shape what 
happens with the RFC...

-> richard

> I haven't implemented completers yet, but that's next on my todo list.
>
> So the question is: should this be part of gogo or do we keep that for karaf ?
> I have the same question for the console: I've started working on an
> advanced console (leveraging jline as we did in karaf / gshell).
>
>    

Mime
View raw message