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
