|Apache Geronimo GShell > Index > Developers > Goals|
GShell is in many ways very similar to Maven (version 2), its actually based on the same core components and uses a lot of the same internal plumbing. Like Maven, GShell has a plugin mechanism to allow the shell's functionality to be augmented as a user requires, though currently (with 1.0-alpha-1) users must manually install the required library files into lib/ and update the layout.xml to include the desired commands. While this is not all that difficult, the process certainly could be improved to make life a little easier on folks...
The idea here is to re-use some of Maven's repository and dependency resolution code to allow GShell plugins to be automatically downloaded from (one or more) remote repositories. This will behave very similarly to Maven, though some custom handling of things like SNAPSHOT artifacts will probably be implemented. Once the GShell core can talk to Maven repositories (local/remote) and can resolve dependencies, then the process of installing new commands (and their dependencies) will become dramatically simplified.
To make this work, we probably need to create an application-level XML configuration file for GShell. This file will contain information like:
The last one here is the kicker... once we can resolve things against remote repositories, then all we have to do is to define the plugin dependencies for the application, and then when first run (or perhaps even first accessed) GShell would fetch the required library files and cache them.
Once cached, the artifact would just be used and no network access would be required (so if the local repository is fully loaded, then no remote repo will even be contacted). We may or may not want to allow any type of SNAPSHOT refreshing muck... simply download and use. Or not... still undecided.
At the moment, the GShell core is a little over a megabyte in girth, probably going to grow a little more as time goes on, but still relatively smallish. This small size, and the ability to automatically populate application libraries means that entire applications (like Geronimo Server) could be distributed as a 1-2mb archive, which when run first will suck down its guts from the network and then fire up just like it was an assembly with a loaded repository.
Along with repository integration will come... supporting commands of course! So one can execute commands to operate on the local repository to like:
And of course access remote repositories to:
To make this work, the plugin mechanism will need to be altered to become repository + dependency aware. This is not a big deal, some XML + model changes, and then soaking up some code from Maven should be all that is needed.
On top of that, some more work (and thinking) needs to be put into the command layout concept. Specifically, plugin artifacts may need to define a default layout for the commands it provides. In most cases that will be a relatively flat tree configuring commands and perhaps even setting some default aliases. The layout manager system should then be able to allow users to configure a way to say:
Basically, this will allow the primary application configuration XML to define its standard layout, and then provide a namespace for command plugins which are dynamically installed later... w/o having them wreck havoc on the standard namespace.
Chances are we'll also have to provide something like Maven's ~/.m2/settings.xml to allow users to tweak things as needed.
The help command ASIS... well, is a complete mess. While it does provide some help, it certainly could be a lot nicer about it, and provide more information.
The idea behind the help command in GShell is like its a combination of the UNIX man command (to get detailed information about a command) and the UNIX ls command (to show what commands are available in a given context).
So, to say get the full help docs for the set command, one might:
This is like man
Or for a specific command in a layout (using relative or absolute paths):
This is like man too.
Or to see what commands I can run in my current context.
This is more like ls...
This form uses the current node (which is just like your current working directory in UNIX) as the context.
Or for the commands in a specific context:
This works, when help resolve the command path to a layout group node, and then it will list only the commands under that group. Perhaps want some more control flags to allow it to decent into children groups too.
Need to update the core framework to allow for flexible and easy to use... yet efficient completion handlers to be installed for commands.
The layout of commands (and groups) available to a user might be limited to their access privileges. So for example, user uberadmin might have all potentially harmful commands like:
and user ubernoob might have a set like:
Need to allow layout navigation to be easy and simple. Some ideas...
When the path resolves to a group node, then treat that like a cd to change the current node to that context.
Allow /foo to always resolve to the root layout's foo command.
Make ../foo resolve to the parent of the current nodes foo command.
Note sure we want to add commands to change context or get the context? Or do we? Do we really need a pwd and a cd ?