You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Kirchev, Lazar" <l....@sap.com> on 2011/10/13 15:34:08 UTC
Gogo help command
Hello,
Currently I am working on a new console for Equinox, which is based on Gogo. I would like to know what do you think about moving the help command from gogo.command bundle to gogo.runtime?
The help command displays both the built-in gogo commands and the user-defined commands. So even if the gogo commands are not available (e.g. the gogo.command bundle is not installed), the help command is still useful in displaying help for the user defined commands as long as the gogo.runtime bundle is active.
Regards,
Lazar
Re: Gogo help command
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/13/11 11:12 , Kirchev, Lazar wrote:
> Thanks Richard,
>
> This would be fine. Then it is not necessary to open a new bug for moving the help command. When do you plan to fix this bug?
When someone finds the time to do it.
-> richard
>
> Regards,
> Lazar
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, October 13, 2011 5:07 PM
> To: users@felix.apache.org
> Subject: Re: Gogo help command
>
> On 10/13/11 09:34 , Kirchev, Lazar wrote:
>> Hello,
>>
>> Currently I am working on a new console for Equinox, which is based on Gogo. I would like to know what do you think about moving the help command from gogo.command bundle to gogo.runtime?
>> The help command displays both the built-in gogo commands and the user-defined commands. So even if the gogo commands are not available (e.g. the gogo.command bundle is not installed), the help command is still useful in displaying help for the user defined commands as long as the gogo.runtime bundle is active.
> I would be ok with that. The real issue, from my point of view, is that
> it seems like we should unify the 'type' and 'help' commands (the former
> is built in and serves a similar purpose)...we have a bug for this:
>
> https://issues.apache.org/jira/browse/FELIX-2340
>
> -> richard
>
>> Regards,
>> Lazar
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Gogo help command
Posted by "Kirchev, Lazar" <l....@sap.com>.
Thanks Richard,
This would be fine. Then it is not necessary to open a new bug for moving the help command. When do you plan to fix this bug?
Regards,
Lazar
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, October 13, 2011 5:07 PM
To: users@felix.apache.org
Subject: Re: Gogo help command
On 10/13/11 09:34 , Kirchev, Lazar wrote:
> Hello,
>
> Currently I am working on a new console for Equinox, which is based on Gogo. I would like to know what do you think about moving the help command from gogo.command bundle to gogo.runtime?
> The help command displays both the built-in gogo commands and the user-defined commands. So even if the gogo commands are not available (e.g. the gogo.command bundle is not installed), the help command is still useful in displaying help for the user defined commands as long as the gogo.runtime bundle is active.
I would be ok with that. The real issue, from my point of view, is that
it seems like we should unify the 'type' and 'help' commands (the former
is built in and serves a similar purpose)...we have a bug for this:
https://issues.apache.org/jira/browse/FELIX-2340
-> richard
>
> Regards,
> Lazar
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo help command
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/13/11 10:41 , Derek Baum wrote:
> The gogo.runtime bundle did once contain commands that were thought to be
> generally useful, but we stripped these out so that gogo.runtime now only
> implements the draft OSGi RFC-147. This allows it to be used elsewhere
> without any "extra" commands not contained in RFC-147.
>
> Maybe the help command (and possibly other non-gogo/felix specific commands)
> should be moved into a new bundle gogo.core?
If we create a combined type/help command, I think it makes sense to
have that as a built-in command, since it provides a basic/general
mechanism to learn about any available commands. Otherwise, though, I do
agree that most commands should provided externally. At this point,
though, I don't really see the need to introduce yet another command bundle.
Essentially, my proposal would be to combine type/help and put in the
runtime. Look at the existing "built-in" commands and remove any that
aren't absolutely necessary. Any removed commands could be added to
either Gogo Command or we could put them in another command bundle.
-> richard
>
> Derek
>
>
> On 13 October 2011 15:06, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 10/13/11 09:34 , Kirchev, Lazar wrote:
>>
>>> Hello,
>>>
>>> Currently I am working on a new console for Equinox, which is based on
>>> Gogo. I would like to know what do you think about moving the help command
>>> from gogo.command bundle to gogo.runtime?
>>> The help command displays both the built-in gogo commands and the
>>> user-defined commands. So even if the gogo commands are not available (e.g.
>>> the gogo.command bundle is not installed), the help command is still useful
>>> in displaying help for the user defined commands as long as the gogo.runtime
>>> bundle is active.
>>>
>> I would be ok with that. The real issue, from my point of view, is that it
>> seems like we should unify the 'type' and 'help' commands (the former is
>> built in and serves a similar purpose)...we have a bug for this:
>>
>> https://issues.apache.org/**jira/browse/FELIX-2340<https://issues.apache.org/jira/browse/FELIX-2340>
>>
>> -> richard
>>
>>
>>> Regards,
>>> Lazar
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo help command
Posted by Derek Baum <de...@baums.org.uk>.
The gogo.runtime bundle did once contain commands that were thought to be
generally useful, but we stripped these out so that gogo.runtime now only
implements the draft OSGi RFC-147. This allows it to be used elsewhere
without any "extra" commands not contained in RFC-147.
Maybe the help command (and possibly other non-gogo/felix specific commands)
should be moved into a new bundle gogo.core?
Derek
On 13 October 2011 15:06, Richard S. Hall <he...@ungoverned.org> wrote:
> On 10/13/11 09:34 , Kirchev, Lazar wrote:
>
>> Hello,
>>
>> Currently I am working on a new console for Equinox, which is based on
>> Gogo. I would like to know what do you think about moving the help command
>> from gogo.command bundle to gogo.runtime?
>> The help command displays both the built-in gogo commands and the
>> user-defined commands. So even if the gogo commands are not available (e.g.
>> the gogo.command bundle is not installed), the help command is still useful
>> in displaying help for the user defined commands as long as the gogo.runtime
>> bundle is active.
>>
>
> I would be ok with that. The real issue, from my point of view, is that it
> seems like we should unify the 'type' and 'help' commands (the former is
> built in and serves a similar purpose)...we have a bug for this:
>
> https://issues.apache.org/**jira/browse/FELIX-2340<https://issues.apache.org/jira/browse/FELIX-2340>
>
> -> richard
>
>
>> Regards,
>> Lazar
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Gogo help command
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/13/11 09:34 , Kirchev, Lazar wrote:
> Hello,
>
> Currently I am working on a new console for Equinox, which is based on Gogo. I would like to know what do you think about moving the help command from gogo.command bundle to gogo.runtime?
> The help command displays both the built-in gogo commands and the user-defined commands. So even if the gogo commands are not available (e.g. the gogo.command bundle is not installed), the help command is still useful in displaying help for the user defined commands as long as the gogo.runtime bundle is active.
I would be ok with that. The real issue, from my point of view, is that
it seems like we should unify the 'type' and 'help' commands (the former
is built in and serves a similar purpose)...we have a bug for this:
https://issues.apache.org/jira/browse/FELIX-2340
-> richard
>
> Regards,
> Lazar
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org