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
