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<[email protected]> 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<[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
>>
>
>
>
> --
> -------------------------------------------------------------------------------------
>
> 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
