geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Please Vote: 1 deployment tool or 2?
Date Thu, 28 Oct 2004 01:37:59 GMT
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


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
>                -behaviors-for-the-same-command-depending-on-what
>                -other-options-are-specified
>>>---------- Forwarded message ----------
>>>Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
>>>From: Aaron Mulder <>
>>>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 
>>>   the 2 usage modes clear.  For example, JSR-88 can't handle creating 
>>>   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 
>>>   modes.  It seems unfortunate that a lot of the command line 
>>>   would clash with each other.
>>> * The code for a unified tool would need to decide how to operate 
>>>   on the mode, and some operations (install/distribute) would need two
>>>   code paths for the same operation, making it harder to have clean 
>>> * The JSR-88 features of a combined tool might work against other 
>>>   (given an appropriate plugin), but the other features would not, 
>>>   would also need to be clarified.
>>> * The current deploy tool would not depend on JSR-88, making it 
>>>   to have a more compact Geronimo distribution with a functional
>>>   deployer, granted without remote deploy or other JSR-88 features.
>>>	Anyway, please vote.
>>>	Aaron

View raw message