Not necesserally sub-shells, but the scope concept is already part of gogo. Each command already has a scope. For example, the bundleContext methods are defined in the "osgi" scope so you can access those using:
$ bundles or $ osgi:bundles This allow disambiguating otherwise ambiguous commands. Derek also fixed some bugs around that. I'm not sure yet, but I think you might change the default scope using $ SCOPE = osgi Hven't tried that though. On Fri, Jul 3, 2009 at 23:46, Richard S. Hall<[email protected]> wrote: > On 7/3/09 12:10 PM, Guillaume Nodet wrote: >> >> I've checked in the prototype into gogo for further discussion. >> See https://svn.apache.org/repos/asf/felix/trunk/gogo/gogo.commands/ >> > > Note, I renamed this to: > > https://svn.apache.org/repos/asf/felix/trunk/gogo/commands/ > > I realized that I had the naming incorrect, even though I changed it a > couple of days ago. > >> I've also fixed the gogo parser a bit as to be slightly more leniant >> when parsing the first argument (so that '/' or '-' could be part of >> the first argument). >> > > Are you imaging the Karaf "sub-shell" concept being part of Gogo? I cannot > say I am a fan of that concept. > > -> richard > >> Feedback welcome ! >> >> On Thu, Jul 2, 2009 at 08:24, Guillaume Nodet<[email protected]> 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. >>> >>> 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). >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> >> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
