Jason, Please send an courtesy heads up email to infrastructure@ when you get a chance.
thanks, dims On Mon, Sep 29, 2008 at 2:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Oh, I also forgot one thing. I registered the gshell.org domain and > set it up to redirect to http://geronimo.apache.org/gshell > automatically. > > I also fixed the redirects in the site content, so actually > http://geronimo.apache.org/gshell will redirect you to > http://cwiki.apache.org/GSHELL. > > The other redirects in the "Support" sidenav in the GSHELL space have > also been updated to work. > > --jason > > > On Tue, Sep 30, 2008 at 1:02 AM, Jason Dillon <[EMAIL PROTECTED]> 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. >> >> CONTAINER >> >> 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. >> >> VFS >> >> 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:[EMAIL PROTECTED]/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. >> >> COMPLETION >> >> Finally implemented completion. Commands that take files, alias names, >> variables names, etc now support tab-completion. Can even complete VFS >> paths! >> >> ALIASES & LINKS >> >> 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. >> >> PLUGINS >> >> 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="http://www.springframework.org/schema/beans"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xmlns:gshell="http://gshell.org/schema/wisdom-gshell"; >> xsi:schemaLocation=" >> http://www.springframework.org/schema/beans >> http://www.springframework.org/schema/beans/spring-beans.xsd >> http://gshell.org/schema/wisdom-gshell >> http://gshell.org/schema/wisdom-gshell/wisdom-gshell.xsd";> >> >> <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. >> >> SIZE >> >> 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. >> >> SPEED >> >> 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 >> https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x >> cd maven-2.0.x >> mvn install >> >> and then: >> >> svn co https://svn.apache.org/repos/asf/geronimo/gshell/trunk gshell >> cd gshell >> mvn >> >> Cheers, >> >> --jason >> >> >> >> >> > -- Davanum Srinivas :: http://davanum.wordpress.com
