Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41804D77.5070508@hiramchirino.com>
Date: Wed, 27 Oct 2004 18:37:59 -0700
From: Hiram Chirino <hiram@hiramchirino.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Please Vote: 1 deployment tool or 2?
References: <Pine.LNX.4.58.0410252243400.24259@saturn.opentools.org>
 <AD5BBB8E-286B-11D9-BEA5-000D93C5B79C@gluecode.com>
 <Pine.LNX.4.58.0410272016210.6113@saturn.opentools.org>
In-Reply-To: <Pine.LNX.4.58.0410272016210.6113@saturn.opentools.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <ammulder@alumni.princeton.edu>
>>>Reply-To: dev@geronimo.apache.org
>>>To: dev@geronimo.apache.org
>>>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
>>>      
>>>
>>    
>>
>
>  
>