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
And of course access remote repositories to:
- Fetch new artifacts
- Query available versions of artifacts
- Refresh artifacts
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:
geronimo:* plugins under path:
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.
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
Or for a specific command in a layout (using relative or absolute paths):
This is like
Or to see what commands I can run in my current context.
This is more like
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.
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.
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:
ubernoob might have a set like:
Remote File Access
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.
/foo to always resolve to the root layout's
../foo resolve to the parent of the current nodes
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
Bash Syntax Support
Whatever else Bash Does...