geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject geronimo-cli, geronimo-deploy-tool and geronimo-commands
Date Wed, 03 Dec 2008 15:20:59 GMT
Folks, why do we need geronimo-cli and geronimo-deploy-tool as well as  
geronimo-commands?  geronimo-cli seems to be the previous command-line  
abstraction bits, and geronimo-deploy-tool their implementation.  I  
think this is all very wasteful since geronimo-commands via GShell  
provides a much richer environment for developing command line tools.

For example with GShell there is no need for the *MetaData, *Args, or  
*ArgsImpl classes.  GShell detects and/or generates  most of this  
stuff automatically.

Looks like most of the geronimo-commands simply adapt GShell's  
argument/option processing to the geronimo-cli bits, then invoke  
geronimo-deploy-tool commands, which then spend most of their life  
doing more argument processing and validation, before they actually do  
any work.  This seems very wasteful.

Additionally there are some integration issues between geronimo-cli  
and gshell mostly relating to IO bits.  For example, DeployUtils  
doesn't use a GShell IO handle, but a ConsoleReader, so its commands  
can't easily detect when --quiet or --verbose was enabled and adjust  
output, or use the io.info(), io.verbose(), io.error() helpers which  
do that for you automatically (with nice Slf4j-style {} argument  
handling).

Basically... I'm wondering why we need to have 2 sets of frameworks  
for cli features.

--jason

Mime
View raw message