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.
*
* @version $Rev$ $Date$
*/
@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 @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 @Argument and @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 @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 <[EMAIL PROTECTED]> 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
