geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Please Vote: 1 deployment tool or 2?
Date Thu, 28 Oct 2004 00:49:47 GMT
	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 
--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
--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


> > ---------- Forwarded message ----------
> > Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
> > From: Aaron Mulder <>
> > Reply-To:
> > To:
> > 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

View raw message