geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon" <>
Subject Re: GShell Update
Date Mon, 29 Sep 2008 18:18:16 GMT
Oh, I also forgot one thing.  I registered the domain and
set it up to redirect to

I also fixed the redirects in the site content, so actually will redirect you to

The other redirects in the "Support" sidenav in the GSHELL space have
also been updated to work.


On Tue, Sep 30, 2008 at 1:02 AM, Jason Dillon <> wrote:
> As some of you might have noticed I've been very busy for the past days
> working on GShell.  I've been meaning to stop hacking and write some email
> about what I'm doing, but I always end up jumping into some feature or
> fixing some bug.  But a lot has changed, so I really need to post some
> details... but rather than go all gooey on the details I am just going to
> point out the major changes.  If anyone wants the gooey stuff, ping me back
> and I can explain in much more detail.
> Spring is used for 99% of the container needs.  Still have some plexus stuff
> around to support maven-artifact-based resolution.
> Dropped gshell-rapture, too much work to keep the plexus glue up to date
> with the spring glue (aka gshell-wisdom).
> Layouts are gone, currently there is only a flat namespace for files... that
> is one of the major things left to be resolved.  Originally I had though of
> the commands namespace like it was a filesystem, and you might even "cd" to
> change the path or whatever, but the VFS work (see below) really showed me
> that was not a good idea.  I am planning on implementing a command
> namespace, just still trying to figure out how.  More to come on this later
> I'm sure.
> The gshell-remote && gshell-whisper stuff is now all spring happy, though it
> still needs to be re-implemented to move more of the configuration stuff
> into the spring context.  There are still a lot of holes in this stuff, as I
> only have been making what was there before work again.  So that is another
> major area which I plan to work on once the framework issues are sorted.
> I18N
> I've hooked up resource bundles for each and every command, and updated the
> CLP stuff to use them for messages related to --help content.   Still need
> to hook up a really simple way to use i18n messages for all user output
> (except logging messages).  But its getting closer.  Related is that
> commands now have a "manual", so if you say "help help" it will show you the
> manual for the "help" command, this text is also externalized for i18n,
> though I've not had time to write a manual for anything so they are all
> todo's right now.  Once things stabilize more we can write those.
> Implemented a bunch more VFS commands to operate on files:
>  cd              Changes the current directory.
>  pwd             Displays the current directory.
>  ls              List the contents of a file or directory.
>  cp              Copies a file or directory.
>  rm              Remove a file or directory.
>  cat             Displays the contents of a file.
>  edit            Edit a file with an external editor.
>  touch           Sets the last-modified time of a file.
>  dir             Link to: ls
>  copy            Link to: cp
>  del             Link to: rm
> Changed all (well most, pending a commit for the script command to use this
> soon) commands to use VFS FileObjects instead of a File/URL, so they can
> take advantage of this flexibility.
> I think this stuff is really cool, and will really be helpful for real-users
> down the line.   For example, with the VFS SFTP provider configured you can
> do something like:
> gshell> cd sftp://myusername:mypassword@somehost/pub
> gshell> ls
> foo.txt bar.txt baz/
> gshell> cat foo.txt
> The cat will show whatever the contents are of foo.txt as you might expect.
> You can also copy files between filesystems, this would copy from the cwd
> (which is still what is set from above) to your local /tmp directory:
> gshell> cp foo.txt /tmp
> And see that its there with:
> gshell> ls /tmp/foo.txt
> Or if you just want to *edit* the contents of the remote file:
> gshell> edit foo.txt
> This will open up an external editor with the contents of foo.txt, you can
> edit, save, close, then the changes are pushed to the remove.  Same works
> for locals, minus the pull and push of content.  Should work on windows,
> though I've not actually tried it to see what breaks.
> Some features left to be done, are implementing a virtual VFS thingy, so you
> can mount/unmount filesystems to get an aggregate view which you can easily
> cd around without needing horrible long URIs.
> Finally implemented completion.  Commands that take files, alias names,
> variables names, etc now support tab-completion.  Can even complete VFS
> paths!
> Added support for command aliases (via "alias foo bar" and "unalias foo") as
> well as linked commands (sorta aliases, but with better completion support).
> Aliases don't show up in 'help' output, they show up under 'alias' output,
> like how it works on a unix shell.  Though please note, that the definition
> syntax does not include a "=" as the syntax parser is still too stupid to
> handle that well.
> Aliases don't have completer, as you can put any string as the value of the
> alias, so its really hard to figure out what command to resolve to and how
> to apply a completer for it.  But I also wanted to provide some way to
> provide a different name for a command, so I implemented a _link_.  Which
> simply defines a new command with a new name and delegates most of the work
> to a target command.  This allows the _linked_ command to pick up the
> completer configuration from its target.  For example, the 'source' command
> can complete any VFS path as its first argument... and the "." link (which
> is a unix shell thingy) performs exactly the same.  Only difference is that
> when you ask for 'help', the help text shows up as "Link to: source".  Right
> now links are not configurable at runtime, they have to be defined in a
> plugins components.xml.
> GShell plugins are now loaded, using configuration in the application.xml
> descriptor to load at boot, or the 'install-plugin' command to dynamically
> install.  For example, right now the gshell-bsf (which supports scripting)
> is not enabled by default, but you can run the shell and install it simply
> by running:
> gshell> install-plugin -g org.apache.geronimo.gshell.commands -a gshell-bsf
> -v 1.0-alpha-2-SNAPSHOT
> Plugins are configured via META-INF/spring/components.xml so you can define
> any required muck there.  But I added some sugar to simplify the wiring of
> the command muck.  Have a peek, this is the components.xml for the
> gshell-bsf (script command) plugin:
> ----8<----
> <beans xmlns=""
>       xmlns:xsi=""
>       xmlns:gshell=""
>       xsi:schemaLocation="
>    <gshell:plugin name="gshell-bsf">
>        <gshell:command-bundle name="default">
>            <gshell:command name="script">
>                <gshell:action
> class="org.apache.geronimo.gshell.commands.bsf.ScriptAction"/>
>                <gshell:completers>
>                    <ref bean="fileObjectNameCompleter"/>
>                    <null/>
>                </gshell:completers>
>            </gshell:command>
>        </gshell:command-bundle>
>    </gshell:plugin>
>    <bean id="bsfManager"
> class="org.apache.geronimo.gshell.commands.bsf.BSFManagerFactoryBean"/>
> </beans>
> ---->8----
> I won't show you what this generates under the covers though... its quite a
> lot of noisy spring beans muck.
> You can also see what plugins are installed with:
> gshell> list-plugins
> I'm still working on the plugin system, so I leave it at that for now.  But
> I plan to add more management commands, make install-plugin be persistable
> (so you can dynamically add a plugin and then on next boot it will
> automatically enable w/o running install-plugin again.
> Plugins are also made up of "bundles", that is so a plugin can define
> smaller chunks of stuff (commands, classpath extentions, whatever) which can
> be enabled/disabled.  For example, a plugin might define a default command
> bundle with user commands, and another command bundle for admin stuff, which
> would require an administrator to enable the bundle before the commands
> could be used.
> Also plugins are intended to have some "activation" muck, which could
> conditionally enable bundles based on some rules, like only enable bundle
> "windowsmuck" when the OS is windows, etc.  Still working all this stuff
> out, but just to give ya an idea of what that stuff is doing.
> So as you might expect, as more features get added, the size of the dist
> gets bigger, and right now its 4.1m (for the bootstrap lib/* stuff).  That
> does not include the gshell-wisdom core and related bits, or plugin bits,
> which get downloaded from a remoteRepository dynamically.  About 1/4 of that
> is to support that artifact resolution, as it requires a lot of Maven
> internal muck to process poms.  I am thinking about ways to reduce that.
>  Also the gshell-wisdom impl uses the spring-context stuff ATM, which adds
> another ~500k and I'm not sure that we really need it.
> Anyways, my point is that its gotten bigger :-(  But I'm looking into
> sliming her down again... w/o loosing any functionality.
> Another thing you might notice if you play with the new shell, is that it
> boots up a lot slower the first time due to all that artifact resolution
> stuff, plugin container construction, etc.  I plan on doing a few rounds of
> optimization of things once some of the other functional issues are wrapped
> up, or close to be wrapped.  So, don't panic ;-)
>  * * *
> Um, I guess I could go on and on, as I keep thinking of stuff I've done
> recently and not included in an update, but this mail is already longer than
> I'd hopped... though covered less than I'd like.  If you are feeling bored,
> give the latest bits a try, its usually in a compilable state.  Though you
> must build maven-2.0.x first because the Maven team never seems to update
> its snapshots.  So if you want to build gshell, then:
> svn co
> cd maven-2.0.x
> mvn install
> and then:
> svn co gshell
> cd gshell
> mvn
> Cheers,
> --jason

View raw message