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

Oh, and one more thing (last time really)...

If you are feeling adventurous you can grab one of the assemblies...  
like:

     http://tinyurl.com/2xn7bm (tar.gz)

or:

     http://tinyurl.com/29zx4w (zip)

--jason

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

> 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
>>
>