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<[email protected]> 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<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
