I guess there are two different ways to name command: * either have a somewhat consistent command name (with lots of commands having the same name) and disambiguating those using scope * try to minimize commands with the same name to avoid having to disambiguate them
In karaf, we mostly use the first way: obr/list obr/addUrl osgi/list features/list features/addUrl admin/list I don't see this way is better than the other. But it may be a bit harder to minimize conflicts without having cumbersome command names. What we have in Karaf is a concept of alias and links, so that we can have both at the same time: explicit command names like features/list (scope = features, name = list) but we can define an alias named "fl" for example ... I guess we can have both of best world this way. Thoughts ? On Sat, Jul 4, 2009 at 16:14, Richard S. Hall<[email protected]> wrote: > On 7/4/09 2:58 AM, David Savage wrote: >> >> Yep that's how it works, Derek's fixes make scope a variable which >> defines a ":" delimited set of scopes to search (in order) for >> commands. >> >> So consider if there were several commands registered in different scopes: >> >> foo:foo >> bar:foo >> bar:bar >> baz:baz >> >> If you were to enter (into the console) >> >> SCOPE=foo:bar:* >> >> Then later when you type "foo" you'd get foo:foo and when you typed >> "bar" you'd get bar:bar. The wild card allows for searching all other >> known scopes, so when you type "baz" you'd get baz:baz. If there were >> another command bam:baz then I believe the * picks the command >> installed first? >> >> This is much like setting the PATH variable in standard shells so you >> get a known version of "ls" vs some random "ls" binary on your file >> system. >> > > I don't have an issue with have a PATH-like concept, but by default all > "scopes" should be on the path unless otherwise specified. I don't want to > be forced into dynamically managing my PATH variable for every set of > commands I want to use. > > Of course, this has implications, because it means you are either do not > generally reuse the same command name for different purposes or use the > command/subcommand approach (like with "obr list"). > > In the latter case, it could be convenient, I suppose if "obr list" were > treated as a scope and command separated by a space, otherwise obr would end > up having a scope and then a command/subcommand. > > -> richard > >> Regards, >> >> Dave >> >> On Sat, Jul 4, 2009 at 7:22 AM, Guillaume Nodet<[email protected]> wrote: >> >>> >>> 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 >>> >>> >> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
