I vote for 1 tool.
To simplify all the modes of operation I would recommend we follow the command structure that tools like "cvs" and "svn" use. So you would like something like:
admin.jar [general options] deploy [list of valid deploy command options] admin.jar [general options] undeploy [list of valid undeploy options] admin.jar [general options] start [list of valid start options] admin.jar [general options] start [list of valid stop options] admin.jar [general options] list modules [list of valid list options] admin.jar [general options] list targets [list of valid list options] admin.jar --help
Regards, Hiram
Aaron Mulder wrote:
I vote for two tools.
If we end up with one tool, here's my thoughts on the syntax. If you read the first few options, you'll understand why I think it's too cumbersome to have one tool.
--install add module to server environment, don't start it.
module AND/OR plan required if no URL is provided
and the deployer JAR is in the destination Geronimo
tree. module AND plan required if a URL is provided.
--url URL to contact the management server. Required if the
deployer JAR is not IN the destination Geronimo
tree or if you want to connect to a remote server or
a server other than Geronimo. Not compatible with
--classPath, --mainClass, or --outfile options. Defaults to null if the command is install and the
--targets option is not specified, or if the mainClass, outfile, or classPath arguments are specified. Defaults to Geronimo on localhost if the start, stop, deploy, undeploy, list-targets, or list-modules commands are given, or the install
command with the --targets option.
--targets a list of targets to get modules for, or to install
or deploy to. defaults to all targets available
from the current management server if a URL is
specified or defaulted to. defaults to the current
server environment only if the URL is null.
--driver JAR of the server driver, if not already on classpath.
only necessary when non-Geronimo server targeted
--module module to install or deploy
--plan deployment plan for module to install or deploy
--classPath classpath to set for an executable module
--mainClass main class for an executable module
--outfile build a CAR instead of deploying into the server environment
--deploy add module to server environment and start it
module and plan are required, targets optional
--start start a module that's available but not running
modulelist required
--stop stop a module that's running
modulelist required
--undeploy stop (if necessary) and remove a module
modulelist required
--modulelist a list of TargetModuleID names to start, stop, or
undeploy
--list-targets gives you a list of targets available from the
management server you connected to
--list-modules gives you a list of modules available from the
management server you connected to. defaults
to all targets, or use --targets
--help this list
--explain-why-there-are-so-many-contradictory-options-and-different
-behaviors-for-the-same-command-depending-on-what
-other-options-are-specified
Aaron
---------- Forwarded message ---------- Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT) From: Aaron Mulder <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vote: 1 deployment tool or 2?
It looks like we'd like to have a command-line deployment tool with JSR-88 features. This would be aimed at providing hot deploy and start/stop and other JSR-88 features, as well as operating on remote servers. It could use the same logic as the Maven plugin or otherwise, I'm not concerned about the implementation yet. The question is:
[ ] Add these features to the existing bin/deployer.jar tool [ ] Create a new bin/xyz.jar tool with only these features, so we have an "offline" deployer and a "JSR-88" or "J2EE" deployer.
The advantage to the unified tool is that you'd have one deployer tool for any scenario. One command to remember, etc.
There are a couple advantages to having separate tools:
* If combined into one tool, the help would need to be rewritten to make
the 2 usage modes clear. For example, JSR-88 can't handle creating a
CAR or executable/classPath information, while the current deployer
can't handle start/stop/undeploy/etc. Also there would need to be
substantial syntax checking to avoid mixing parameters from different
modes. It seems unfortunate that a lot of the command line arguments
would clash with each other.
* The code for a unified tool would need to decide how to operate based
on the mode, and some operations (install/distribute) would need two
code paths for the same operation, making it harder to have clean code.
* The JSR-88 features of a combined tool might work against other servers
(given an appropriate plugin), but the other features would not, which
would also need to be clarified.
* The current deploy tool would not depend on JSR-88, making it possible
to have a more compact Geronimo distribution with a functional
deployer, granted without remote deploy or other JSR-88 features.
Anyway, please vote.
Thanks,
Aaron
