Goals

Repository and Dependency Integration

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:

• Path to the local repository cache
• List of remote repositories to query
• Application layout (and possibly rules on how to apply plugin layouts)
• Properties (ie. gsh.properties)
• Branding configuration
• Plugin and dependency configuration

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:

• List all artifacts under a groupId
• Search for artifacts using regex
• Get details on an artifact
• Remove an artifact (perhaps even purge all trans dependencies?)
• Backup the repository
• Restore the repository
• Etc.

And of course access remote repositories to:

• Fetch new artifacts
• Query available versions of artifacts
• Refresh artifacts
• Etc.

Dependencies

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:

Map all default plugin layouts under path: /plugins

or:

Map the geronimo:* plugins under path: /geronimo/
1.

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.

Re-implement help

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:

help set

This is like man

Or for a specific command in a layout (using relative or absolute paths):

help geronimo/start-server

This is like man too.

Or to see what commands I can run in my current context.

help

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:

help geronimo

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.

Command-line (and option + whatever) Completion

Need to update the core framework to allow for flexible and easy to use... yet efficient completion handlers to be installed for commands.

Role-based Layouts

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:

• shutdown
• kill
• abort
• do-something-nasty
• ...

and user ubernoob might have a set like:

• statistics
• do-something-which-will-not-break-anything

Remote Shell

TODO

Remote File Access

TODO

Layout Navigation (and easy sub-shells)

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 ?

Bash Syntax Support

TODO

Pipes

TODO

Sub-shells

TODO

Redirection

TODO

Functions

TODO

Whatever else Bash Does...

TODO