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
>
>
