geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: structure of GShell commands
Date Fri, 14 Dec 2007 15:29:40 GMT
The structure is just for namespace, you can arrange commands however  
you like... one of the benefits of GShell.

I just setup the structure, cause I'm anal and I organize  
everything... er except my bedroom, which is a huge cluster*uck.

  * * *

My _recommendation_ is to have some sort of organization... though it  
doesn't need to be "geronimo/*"...

Assuming that the configuration of GShell is specific to Geronimo,  
then lets consider what someone using the interface might want/expect/ 
need?  But also keep in mind that they are free to drop in other  
commands, like the BSF scripting bits (the 'script' command) or the  
VFS commands (currently only 'copy') or remote support ('remote- 
shell', 'rsh', 'remote-shell-server', 'rshd').

I'm not sure what the right organization is really... cause we are  
just getting things rolling in this direction.

So I say we take a stab at what we *think* folks want, then do it...  
and make changes later as needed.  IMO there is no reason not to  
change something if we are making it easier/better.


On Dec 13, 2007, at 5:22 AM, Matt Hogstrom wrote:

> If GShell would be targeted at more servers than G then I think  
> these commands should be under geronimo.  If not, then I think a  
> flat structure makes sense.
> On Dec 11, 2007, at 10:04 AM, Kevan Miller wrote:
>> We currently have the following structure for Geronimo GShell  
>> commands:
>> geronimo/
>> 	start-server
>> 	stop-server
>> 	start-client
>> deploy/
>> 	install-library
>> 	disconnect
>> 	deploy
>> 	...
>> This doesn't make much sense to me. Let's either assume GShell is  
>> used for Geronimo server or assume that GShell can be used for  
>> multiple target environments, but not both...
>> I think the current deploy/ commands should be under the geronimo  
>> tree. What do others think? I think applying a bit more structure,  
>> now, will minimize entropy over time...
>> Anybody want to have a shot at proposing a command structure?
>> --kevan

View raw message