You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/07/02 08:24:10 UTC
[gogo] Advanced commands / console
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
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
That's the way it currently works. The prototype i've been working is
completely separated from the runtime.
The way it works is that it simply register a Function with the two
mandatory properties for gogo to recognize it as a shell command.
So it's completely optional.
On Thu, Jul 2, 2009 at 16:03, David Savage<da...@paremus.com> wrote:
> Possibly harder to do, but might be nice if extra features were opt
> in? So the default impl is as close to the spec as possible but it can
> be extended for other projects that want to etc. Potentially via other
> services/bundles? We are talking about OSGi after all ;)
>
> On Thu, Jul 2, 2009 at 2:53 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> 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).
>>>
>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [gogo] Advanced commands / console
Posted by David Savage <da...@paremus.com>.
Possibly harder to do, but might be nice if extra features were opt
in? So the default impl is as close to the spec as possible but it can
be extended for other projects that want to etc. Potentially via other
services/bundles? We are talking about OSGi after all ;)
On Thu, Jul 2, 2009 at 2:53 PM, Richard S. Hall<he...@ungoverned.org> wrote:
> 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).
>>
>>
>
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
The interface and the 3 annotations are not tied to blueprint.
The wrapper command is mostly unaware of blueprint but for the
conversion of arguments (as blueprint as some very nice converter
specified), but this part could be made abstract and have two
implementations, one being able to leverage blueprint and another one
that would be without additional requirement.
On Thu, Jul 2, 2009 at 15:53, Richard S. Hall<he...@ungoverned.org> wrote:
> 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).
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [gogo] Advanced commands / console
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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).
>
>
Re: [gogo] Advanced commands / console
Posted by Derek Baum <de...@paremus.com>.
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 <gn...@gmail.com>
> 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<he...@ungoverned.org> 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<gn...@gmail.com>
> 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<he...@ungoverned.org>
> >>> 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<gn...@gmail.com>
> >>>>> 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
>
Re: [gogo] Advanced commands / console
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/4/09 12:28 PM, Guillaume Nodet wrote:
> 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.
>
In general, I think it is fine for commands that already use the
command/subcommand approach to try to be consistent in their
subcommands, but I am not really interested in trying to force all
commands to use the command/subcommand approach. I would like it to work
like a normal shell in most cases.
-> richard
> 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<he...@ungoverned.org> 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<gn...@gmail.com> 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<he...@ungoverned.org>
>>>> 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<gn...@gmail.com>
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
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<he...@ungoverned.org> 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<gn...@gmail.com> 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<he...@ungoverned.org>
>>> 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<gn...@gmail.com>
>>>>> 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
Re: [gogo] Advanced commands / console
Posted by Derek Baum <de...@paremus.com>.
2009/7/5 Richard S. Hall <he...@ungoverned.org>
> On 7/4/09 11:42 AM, Derek Baum wrote:
>
>>
>> You can then choose how you want to invoke them:
>>
>> 1. explicitly - obr:list, posix:grep
>> 2. using your proposal - 'obr list', 'posix grep'
>> 3. using SCOPE=posix:* - allows typing just 'grep' or 'ls'
>>
>>
>
> 4. Just type 'grep'.
>
> Right? If all scopes are searched and since 'grep' is unique, then I
> shouldn't need to type anything else, nor should I have to change the scope.
>
> -> richard
yes, exactly.
when commands are unique (which they usually will be), you should just type
their simple name.
When commands are not unique, and you care which one you get (for example
osgi:bundles and local:bundles), then you can solve the ambiguity in the
same way as you would in a *nix shell - by using an absolute path for the
command or by setting PATH.
Derek
Re: [gogo] Advanced commands / console
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/4/09 11:42 AM, Derek Baum wrote:
> 2009/7/4 Richard S. Hall<he...@ungoverned.org>
>
>> 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.
>>
>
>
> I like this idea - if the command name matches a known scope, then execute
> the next argument as a command in that scope. This also makes creating
> commands with sub-commands no different than other commands.
>
> However, we'd need to define what should happen if 'obr' is typed without a
> sub-command - it could try to execute obr:help or obr:default if they exist,
> or just give a 'sub-command not found' error.
>
>
> You could define closely related obr commands and loosely related posix
> commands in the same way
> (i.e. there is no need to add extra logic to the obr command to handle
> sub-commands):
>
> obr:list
> obr:add
> etc
>
> posix:grep
> posix:ls
> etc
>
> You can then choose how you want to invoke them:
>
> 1. explicitly - obr:list, posix:grep
> 2. using your proposal - 'obr list', 'posix grep'
> 3. using SCOPE=posix:* - allows typing just 'grep' or 'ls'
>
4. Just type 'grep'.
Right? If all scopes are searched and since 'grep' is unique, then I
shouldn't need to type anything else, nor should I have to change the scope.
-> richard
> You could also set SCOPE=obr:*, which would allow you to just type 'list'
> and 'add' for obr commands,
> but this is probably less useful as the obr command names are more likely to
> collide with other scopes.
>
> Derek
>
>
>
>> -> richard
>>
>>
>
>
Re: [gogo] Advanced commands / console
Posted by Derek Baum <de...@paremus.com>.
2009/7/4 Richard S. Hall <he...@ungoverned.org>
>
> 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.
Yes, all scopes are searched by default.
If SCOPE is not set, then it defaults to "osgi:*", which first searches the
osgi: scope, then all other scopes.
The commands are stored in a HashMap, so if an explicit scope is not given
and multiple commands are registered, then you don't know which one you'll
get.
Note: RFC-132 does not currently define the commands that shoulkd be in the
osgi: scope
>
> 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.
I like this idea - if the command name matches a known scope, then execute
the next argument as a command in that scope. This also makes creating
commands with sub-commands no different than other commands.
However, we'd need to define what should happen if 'obr' is typed without a
sub-command - it could try to execute obr:help or obr:default if they exist,
or just give a 'sub-command not found' error.
You could define closely related obr commands and loosely related posix
commands in the same way
(i.e. there is no need to add extra logic to the obr command to handle
sub-commands):
obr:list
obr:add
etc
posix:grep
posix:ls
etc
You can then choose how you want to invoke them:
1. explicitly - obr:list, posix:grep
2. using your proposal - 'obr list', 'posix grep'
3. using SCOPE=posix:* - allows typing just 'grep' or 'ls'
You could also set SCOPE=obr:*, which would allow you to just type 'list'
and 'add' for obr commands,
but this is probably less useful as the obr command names are more likely to
collide with other scopes.
Derek
>
>
> -> richard
>
Re: [gogo] Advanced commands / console
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<gn...@gmail.com> 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<he...@ungoverned.org> 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<gn...@gmail.com> 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
>>
>>
>
>
>
>
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
Great, thx a lot for this explanation.
Btw, I've create the main page for gogo doc at
http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Gogo
So everyone is welcome to add some content to it.
On Sat, Jul 4, 2009 at 08:58, David Savage<da...@paremus.com> 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.
>
> Regards,
>
> Dave
>
> On Sat, Jul 4, 2009 at 7:22 AM, Guillaume Nodet<gn...@gmail.com> 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<he...@ungoverned.org> 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<gn...@gmail.com> 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
>>
>
>
>
> --
> -------------------------------------------------------------------------------------
>
> Paremus Limited. Registered in England. Registration No. 4181472
>
> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
>
> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
>
> The information transmitted is intended only for the person(s) or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended recipient
> is prohibited.
>
> If you received this in error, please contact the sender and delete
> the material from any computer.
>
> -------------------------------------------------------------------------------------
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [gogo] Advanced commands / console
Posted by David Savage <da...@paremus.com>.
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.
Regards,
Dave
On Sat, Jul 4, 2009 at 7:22 AM, Guillaume Nodet<gn...@gmail.com> 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<he...@ungoverned.org> 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<gn...@gmail.com> 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
>
--
-------------------------------------------------------------------------------------
Paremus Limited. Registered in England. Registration No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.
If you received this in error, please contact the sender and delete
the material from any computer.
-------------------------------------------------------------------------------------
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
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<he...@ungoverned.org> 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<gn...@gmail.com> 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
Re: [gogo] Advanced commands / console
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<gn...@gmail.com> 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
>>
>>
>
>
>
>
Re: [gogo] Advanced commands / console
Posted by Guillaume Nodet <gn...@gmail.com>.
I've checked in the prototype into gogo for further discussion.
See https://svn.apache.org/repos/asf/felix/trunk/gogo/gogo.commands/
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).
Feedback welcome !
On Thu, Jul 2, 2009 at 08:24, Guillaume Nodet<gn...@gmail.com> 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