Folks, the majority of the issues (mostly legal muck) and a few small
bugs/improvements have been cleaned up for the 1.0-alpha-1 release of
GShell.
There is one issue which has been pointed out regarding the 'help'
command, which ATM is less than ideal, but does show the information.
The idea of the 'help' command is to be sort of a combination of 'ls'
and 'man', so that running it with no argument shows the commands
available in the current context, and running with an argument, the
argument is assumed to be a command path, which is resolved and the
help docs for the command are displayed.
To make this work is a little bit more than a minor change, and I've
planned to get it fixed up for the next version (hopefully in a few
months)... and really, this is a moderately complex command which is
well suited for someone wanting to learn more about how GShell works
to tackle (which another reason why I didn't make it all super-uber-
sexy).
BUT... I think we really need to get 1.0-alpha-1 released, so it can
be consumed by G 2.1 (as well as other projects which are starting to
use GShell). And IMO, the 'help' commands ugliness is not a big
enough priority to delay the release.
IMO, GShell is still a work in progress, while quite functional for
many purposes, its still a little rough around the edges and will take
some more love to sift through the issues, flesh out the features and
iron those pesky buggers out. My recommendation is that for G 2.1
that we don't advertise GShell as a _feature_, but just let it be
ASIS, handling the CLI bits for G and average users won't really know
the difference. Advanced folks might want to play with it, which is
fine (good even to get more feedback), but I don't think that G 2.1 is
the release where we want to unleash this on to the world.
I would rather let GShell cook... and then simmer for a while longer,
pull in more feedback (as now more folks are starting to be aware of
the framework and are implementing tools with it *yay*), fix up the
architecture, fill in some major holes, write some *real*
documentation, and then hand it to the masses... perhaps in G 2.2.
Though keep in mind, GShell isn't really Geronimo-specific... its
intended to be a light(ish) framework for building rich command-line
applications. It just so happens that Geronimo needs such a system to
handle its growing cli needs. And GShell's remote login feature makes
it ideal for administrators to use that cli to perform installs,
maintenance, scripts ala BSF or whatever.
Geronimo is definitely, well... IMO, an ideal candidate for GShell
integration and I really believe that there is a *huge* value add
here. But... before we go telling the world how dope the GShell
integration in Geronimo is... I'd really like to fix some of its warts
and create some documentation.
* * *
Anyways, the point of this email is really to ask you folks... can we
live with how GShell works right now for the 1.0-alpha-1 release? Or
are their any blocking issues which *must* be resolved?
I'd really like to spin up a vote today or tomorrow... so if anyone
has any input... now is the time.
--jason
PS. Thanks for those of you who have taken time to play with GShell
and provided feedback. Your input is invaluable and IMO critical to
the growth and success of GShell. So thanks again!
- GShell 1.0-alpha-1 release update Jason Dillon
-
