Re: Porting the cli deployer/geronimo-cli bits to GShell

One more thing.... I published snaps earlier today and just pushed  
out the latest site, which you can see here:

     http://geronimo.apache.org/maven/gshell/

(Gonna take a wee bit for it to sync).

Its a typical empty looking Maven site, but has and aggregated  
Javadocs page here if you want to see what's there:

     http://geronimo.apache.org/maven/gshell/apidocs/index.html

--jason

On Oct 1, 2007, at 2:07 AM, Jason Dillon wrote:

> Its *relatively* simple... just a matter of picking one of the  
> easier commands that doesn't need a bunch of magically class- 
> loading muck.
>
> There are 2 command instances right now in the geronimo-commands  
> module (start-server and stop-server).  To create a new command is  
> very simple, simply create a new .java or .groovy (I'd go  
> for .groovy right now) source in the tree, like say a 'list- 
> modules' command:
>
> <snip>
> import org.apache.geronimo.gshell.command.annotation.CommandComponent
> import org.apache.geronimo.gshell.command.CommandSupport
>
> /**
>  * List the running modules in a Geronimo server.
>  *
>  *  <at> version $Rev$ $Date$
>  */
>  <at> CommandComponent(id='list-modules')
> class ListModulesCommand
> 	extends CommandSupport
> {
>     protected Object doExecute() throws Exception {
>         io.out.println('Hello World')
>
>         log.debug("This is our happy happy instance: {}", this)
>
>         // TODO: Do something more useful
>
>         return SUCCESS
>     }
> }
> </snip>
>
> You need to annotate the command with the  <at> CommandComponent  
> annotation and give it an ID, which for right now ends up being the  
> command-name you'd execute in the shell.  Extend from  
> CommandSupport to pick up some plumbing... and then implement  
> doExecute().
>
> You can peep at the StartServerCommand to see how annotations are  
> used to handle command-line arguments and options.  The  
> CommandSupport muck handles invoking the CLP (command-line  
> processor) bits to detect the  <at> Argument and  <at> Option annotations and  
> then inject the values accordingly.
>
> CommandSupport also sets up the command's IO instance, which is  
> basically just a container for input/output streams and their  
> reader/writer equivalents.  The 'io' instance is used to spit out  
> just to the user, like:
>
>     io.out.println('Hi there')
>
> Which as you might guess is very similar to a System.out.println(),  
> though the IO instance is used because the shell could be remote  
> running over TCP+SSL or embedded in another shell, etc.
>
> The  <at> CommandComponent tells the gshell-maven-plugin to include that  
> command-instance when generating the classes/META-INF/gshell/ 
> commands.xml descriptor (which is very similar to a Plexus  
> commands.xml or a Maven plugin.xml)... in that its auto-generated  
> from meta-data and the shell knows how to dynamically discover new  
> sets of commands by looking for META-INF/gshell/commands.xml  
> resources.
>
> Anyways, IMO the biggest thing right now is going to be figuring  
> out which of the deployer.jar commands can be easily re-crafted as  
> GShell commands w/o having to bring in a full Kernel or otherwise  
> augmenting the shell's classpath.  Basically, anything that  
> currently lives in lib/* or in lib/gshell/* can be easily  
> accessed.  Other bits which require a repository and bootstrap  
> kernel will require a bit more work for me to adapt and simplify  
> for easier integration... but its defs on the list.
>
>  * * *
>
> I'm probably going to take a break from the GShell rsh/rsh-server  
> bits for a little while to let all that stuff settle in my head  
> (and hopefully get some other eyes on the codebase too... extra  
> eyes are always helpful).  And I'd like to finish up and get the  
> startup/shutdown bits all integrated with GShell and then start to  
> tackle the deployer and client cli bits which are remaining.
>
> There are also lots of little bits here and there that need more  
> attention.  Like for example, I've yet to configure the start- 
> server or stop-server commands to allow command-line arguments/ 
> options to set the hostname, port, username, password bits.  That  
> should be relatively simple and perhaps not a bad place to start to  
> get your feet wet and learn about some more GShell (which will rule  
> the world one of these days... I'm telling ya).
>
> Aighty... I'll stop babbling now.  Please lemme know if you have  
> any questions, comments, suggestions or otherwise.  I'm hoping to  
> entice a few more folks to at least start looking over the  
> codebase, asking questions or whatever.
>
> Cheers,
>
> --jason
>
>
> On Oct 1, 2007, at 1:35 AM, Jacek Laskowski wrote:
>
>> On 10/1/07, Jason Dillon <jason@...> wrote:
>>
>>> But is there anyone out there that might want a taste of GShell?  I
>>> could use a hand...
>>
>> Be on irc tonight (CET) - I'd like to see how uber-trivial it is 
>> Others invited.
>>
>> Jacek
>>
>> -- 
>> Jacek Laskowski
>> http://www.JacekLaskowski.pl
>