I don't think we need to be prescriptive here, as we can support both models at the same time.
It is also not generally possible to avoid command name conflicts, since the container is extensible and we don't know what command names any external bundles providing commands might register. Derek 2009/7/4 Guillaume Nodet <[email protected]> > 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 >
