You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/10/26 04:44:41 UTC
Please Vote: 1 deployment tool or 2?
I only got one vote on this, and it wasn't from a committer.
Please everyone take a look and send along your vote.
Thanks,
Aaron
---------- Forwarded message ----------
Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
From: Aaron Mulder <am...@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
Re: Please Vote: 1 deployment tool or 2?
Posted by Bruce Snyder <fe...@frii.com>.
Aaron Mulder wrote:
> [X ] 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.
Hiram Chirino wrote:
> 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
I really like Hiram's idea above. IMO, our goal is to make things
easier, not more complex. I think that a single tool will be easier to
understand than two. Additionally, a simplified command set within the
single tool will further ease the deployment process.
Bruce
--
perl -e 'print
unpack("u30","<0G)U8V4\\@4VYY9&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Please Vote: 1 deployment tool or 2?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <am...@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
>>>
>>>
>>
>>
>
>
>
Re: Please Vote: 1 deployment tool or 2?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 28 Oct 2004, Dain Sundstrom wrote:
> Who cares? I don't think we should limit our selves to pure 88 just so
> we can have support for other servers. Frankly, I would be shocked if
> anyone used our command line tool for anther server, when every server
> ships with a tool custom to the server (with enhancements).
> ...
> I was totally with you, up to this section. I don't think we shoe horn
> it at all. If you are running offline, you simply execute the exiting
> code, which isn't 88 at all. Use 88 when it is nice fit and something
> custom when it isn't.
> ...
> Again, I frankly don't care what 88 says is legal. Geronimo lets you
> deploy most application without plans. David Jencks just committed a
> big change to resource adapter naming so most ears don't need a plan at
> all. If we followed this logic, we would have to have the following
> plan most of the time:
OK, it just feels like we're taking advantage of undocumented
features. Even it they're our own undocumented features. :)
Aaron
Re: Please Vote: 1 deployment tool or 2?
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 28, 2004, at 11:35 AM, Aaron Mulder wrote:
> On Thu, 28 Oct 2004, Dain Sundstrom wrote:
>> These are the main commands. I like hiram's idea of dropping the --
>> from them like svn and cvs do. I don't see why you have extra
>> restrictions on install. Actually, why not just drop install since it
>> is just deploy?
>
> Sure, we can restructure the syntax. The difference
> between install and deploy would be clearer if we called them
> "distribute"
> and "deploy" to match the JSR-88 terms -- I only used "install"
> because I
> thought we wanted to preserve the existing syntax. So long as we're
> going
> to change it anyway...
> But the difference is that "distribute" does not start a module,
> so "deploy == distribute + start". In concept, you could distribute an
> app, make sure it gets processed and loaded on to all the servers, and
> then bang! issue a start command to start them all at once. I guess.
> I
> don't really plan to use that much myself, but since the API
> capability is
> there, why not allow it from the tool? We can just list that under
> "rarely used".
+ 1
> Also, "start" is not meaningful for the current deployer -- not
> only can it not start because the server is not running, it does not
> alter
> the configuration in such a way that the module should be started next
> time the server is started. So "install" in the current tool really is
> equivalent to "distribute" not "deploy". If we want the default
> command
> to be "deploy", then when the tool runs in "server is offline" mode
> (like
> the current tool), it should update var/config/config.list to add the
> module to that.
+1
>>> --modulelist a list of TargetModuleID names to start, stop, or
>>> undeploy
>>>
>>> --list-modules gives you a list of modules available from the
>>> management server you connected to. defaults
>>> to all targets, or use --targets
>
>> What is the difference between these two?
>
> Well, when starting, stopping, or undeploying, you must give the
> server a list of TargetModuleIDs to start, stop, or undeploy. Where a
> TargetModuleID is some product-specific amalgamation of a unique
> server or
> cluster ("Target") ID and a module ID. So if the same EAR is deployed
> on
> 3 servers, you could stop it on 2 of them with 2 TargetModuleID's.
> We'll
> have to think about what our Target IDs should look like, but they'll
> likely be ugly (host name and installation path, perhaps?) or else a
> unique name that a user configures somewhere, and the Target Module
> ID's
> will presumably be that plus either a ConfigId or ObjectName
> identifying
> the module. I need to look at what the current TargetModuleID
> implementation does.
>
> Anyway, one of these arguments gives the list of TargetModuleIDs
> that you want to start, stop, etc. The other is an inquiry command,
> where
> you give it a list of targets, and it gives you back a list of
> TargetModuleIDs available on those targets. So if you don't know what
> you're dealing with, it might go like this:
>
>>>> deployer list-targets
> server1
> server2
> cluster
>>>> deployer list-modules --targets cluster
> cluster/app1.ear
> cluster/webapp2.war
> cluster/dbpool.rar
>>>> deployer stop --modules cluster/webapp2.war,cluster/app1.ear
> cluster/app1.ear stopped
> cluster/webapp2.war stopped
>
> Perhaps we could omit the --modules argument and just assume
> everything at
> the end of the command without a -- prefix is a module to operate on.
+1
>>> --list-targets gives you a list of targets available from the
>>> management server you connected to
>>>
>>> --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.
>>
>> These are almost never going to be used, so should be documented as
>> such
>
> Well, until we implement clusters, or a single administration
> point for multiple servers (similar to WebLogic admin server + many
> managed servers).
Ya, but until we implement clusters, I doubt they will be used, and
then we won't need them :)
>>> --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
>>
>> Options of creating an output Jar... these are rarely used and should
>> be documented as such.
>
> I don't like them at all because they can't be done via JSR-88.
> So this introduces not only an additional implementation path, but also
> incompatibility with many of the other options that require JSR-88.
What do we care about 88 purity? We can add what ever we want to our
own tool. If someone wants to use a limited cross platform tool, the
can still use our raw driver.
> If nothing else, can we please please have another tool just to build
> output JARs? This mode of operation has no relation to the normal
> deployer operation.
I agree, but that is another tool for another day.
> (Though in truth, deploying while the server is not
> running has the same disadvantage.)
And it has some advantages... like if you mess up you server so it
won't start, you can start over by redeploying the server plan.
>>> --driver JAR of the server driver, if not already on
>>> classpath.
>>> only necessary when non-Geronimo server targeted
>>
>> I don't think there is any reason for us to support other app servers
>> drivers. This is a tool by geronimo for geronimo. Let the ide
>> vendors
>> come up with the universal adapter.
>
> If we implement it using JSR-88, which is the most straightforward
> way for all normal operations (so long as the server is running), then
> we
> get support for other app servers for free.
Who cares? I don't think we should limit our selves to pure 88 just so
we can have support for other servers. Frankly, I would be shocked if
anyone used our command line tool for anther server, when every server
ships with a tool custom to the server (with enhancements).
> Deployment while the server is not running is the tricky case.
> We can shoehorn it into JSR-88 by having a URL mode that requires that
> a
> local Kernel be started before JSR-88 is invoked (like the way the
> deployer tool runs now), but Jeremy seemed to be strongly opposed to
> this.
> I don't really like having 2 different code paths for standard
> operation,
> though, so if we go with one tool I might favor this, hacky as it is.
I was totally with you, up to this section. I don't think we shoe horn
it at all. If you are running offline, you simply execute the exiting
code, which isn't 88 at all. Use 88 when it is nice fit and something
custom when it isn't.
>> So I see the following as being the most common usage:
>>
>> deployer deploy funk.war
>> deployer undeploy funk
>
> Unfortunately, both of these are illegal according to JSR-88. You
> need to specify a deployment plan for the module, and to undeploy you
> need to specify a target module ID including the target name and the
> module name.
Again, I frankly don't care what 88 says is legal. Geronimo lets you
deploy most application without plans. David Jencks just committed a
big change to resource adapter naming so most ears don't need a plan at
all. If we followed this logic, we would have to have the following
plan most of the time:
<?xml>
<plan/>
> We could build a workaround for the first -- if no plan is
> specified we load the driver, assume the driver loads the plan or
> creates a default one from deployment information in the archives, save
> the plan to a temp file, and then send the module and plan together as
> required and delete the temp file.
No just pass a null plan to our driver, and it will happily continue
without one.
> For the second one, we'd assume you want to operate on all
> targets. Then we'd get the list of all TargetModuleIDs for all
> targets,
> and for each, check if the name you specified is either equal to
> TargetModuleID.toString, or TargetModuleID.getModuleID.
Sure... what ever we are doing today in the maven plugin
> So I guess we could support both usages with a sufficiently
> clever tool.
+1
> I'm thinking that the current Commons CLI logic for the arguments
> isn't going to work, since there will be different available arguments
> depending on your primary command. Perhaps we can read the first
> argument
> and then construct a different CLI chain accordingly.
I don't know. There is a new version of the CLI package that may
support this, but if it doesn't, I would just write some code that can
parse all arguments and have an external method that does the semantic
verification.
> Also, with all the votes for 1 tool, I'm assuming that you're OK
> with the basic Geronimo deployment tool depending on JSR-88.
Yes
-dain
Re: Please Vote: 1 deployment tool or 2?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 28 Oct 2004, Dain Sundstrom wrote:
> These are the main commands. I like hiram's idea of dropping the --
> from them like svn and cvs do. I don't see why you have extra
> restrictions on install. Actually, why not just drop install since it
> is just deploy?
Sure, we can restructure the syntax. The difference
between install and deploy would be clearer if we called them "distribute"
and "deploy" to match the JSR-88 terms -- I only used "install" because I
thought we wanted to preserve the existing syntax. So long as we're going
to change it anyway...
But the difference is that "distribute" does not start a module,
so "deploy == distribute + start". In concept, you could distribute an
app, make sure it gets processed and loaded on to all the servers, and
then bang! issue a start command to start them all at once. I guess. I
don't really plan to use that much myself, but since the API capability is
there, why not allow it from the tool? We can just list that under
"rarely used".
Also, "start" is not meaningful for the current deployer -- not
only can it not start because the server is not running, it does not alter
the configuration in such a way that the module should be started next
time the server is started. So "install" in the current tool really is
equivalent to "distribute" not "deploy". If we want the default command
to be "deploy", then when the tool runs in "server is offline" mode (like
the current tool), it should update var/config/config.list to add the
module to that.
> > --modulelist a list of TargetModuleID names to start, stop, or
> > undeploy
> >
> > --list-modules gives you a list of modules available from the
> > management server you connected to. defaults
> > to all targets, or use --targets
> What is the difference between these two?
Well, when starting, stopping, or undeploying, you must give the
server a list of TargetModuleIDs to start, stop, or undeploy. Where a
TargetModuleID is some product-specific amalgamation of a unique server or
cluster ("Target") ID and a module ID. So if the same EAR is deployed on
3 servers, you could stop it on 2 of them with 2 TargetModuleID's. We'll
have to think about what our Target IDs should look like, but they'll
likely be ugly (host name and installation path, perhaps?) or else a
unique name that a user configures somewhere, and the Target Module ID's
will presumably be that plus either a ConfigId or ObjectName identifying
the module. I need to look at what the current TargetModuleID
implementation does.
Anyway, one of these arguments gives the list of TargetModuleIDs
that you want to start, stop, etc. The other is an inquiry command, where
you give it a list of targets, and it gives you back a list of
TargetModuleIDs available on those targets. So if you don't know what
you're dealing with, it might go like this:
>>> deployer list-targets
server1
server2
cluster
>>> deployer list-modules --targets cluster
cluster/app1.ear
cluster/webapp2.war
cluster/dbpool.rar
>>> deployer stop --modules cluster/webapp2.war,cluster/app1.ear
cluster/app1.ear stopped
cluster/webapp2.war stopped
Perhaps we could omit the --modules argument and just assume everything at
the end of the command without a -- prefix is a module to operate on.
> > --list-targets gives you a list of targets available from the
> > management server you connected to
> >
> > --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.
>
> These are almost never going to be used, so should be documented as such
Well, until we implement clusters, or a single administration
point for multiple servers (similar to WebLogic admin server + many
managed servers).
> > --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
>
> Options of creating an output Jar... these are rarely used and should
> be documented as such.
I don't like them at all because they can't be done via JSR-88.
So this introduces not only an additional implementation path, but also
incompatibility with many of the other options that require JSR-88. If
nothing else, can we please please have another tool just to build
output JARs? This mode of operation has no relation to the normal
deployer operation. (Though in truth, deploying while the server is not
running has the same disadvantage.)
> > --driver JAR of the server driver, if not already on classpath.
> > only necessary when non-Geronimo server targeted
>
> I don't think there is any reason for us to support other app servers
> drivers. This is a tool by geronimo for geronimo. Let the ide vendors
> come up with the universal adapter.
If we implement it using JSR-88, which is the most straightforward
way for all normal operations (so long as the server is running), then we
get support for other app servers for free.
Deployment while the server is not running is the tricky case.
We can shoehorn it into JSR-88 by having a URL mode that requires that a
local Kernel be started before JSR-88 is invoked (like the way the
deployer tool runs now), but Jeremy seemed to be strongly opposed to this.
I don't really like having 2 different code paths for standard operation,
though, so if we go with one tool I might favor this, hacky as it is.
> So I see the following as being the most common usage:
>
> deployer deploy funk.war
> deployer undeploy funk
Unfortunately, both of these are illegal according to JSR-88. You
need to specify a deployment plan for the module, and to undeploy you
need to specify a target module ID including the target name and the
module name.
We could build a workaround for the first -- if no plan is
specified we load the driver, assume the driver loads the plan or
creates a default one from deployment information in the archives, save
the plan to a temp file, and then send the module and plan together as
required and delete the temp file.
For the second one, we'd assume you want to operate on all
targets. Then we'd get the list of all TargetModuleIDs for all targets,
and for each, check if the name you specified is either equal to
TargetModuleID.toString, or TargetModuleID.getModuleID.
So I guess we could support both usages with a sufficiently
clever tool.
I'm thinking that the current Commons CLI logic for the arguments
isn't going to work, since there will be different available arguments
depending on your primary command. Perhaps we can read the first argument
and then construct a different CLI chain accordingly.
Also, with all the votes for 1 tool, I'm assuming that you're OK
with the basic Geronimo deployment tool depending on JSR-88.
Aaron
Re: Please Vote: 1 deployment tool or 2?
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Oct 27, 2004, at 5:49 PM, 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.
I think the problem is your are trying to write the "universal adapter"
> --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.
>
> --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
These are the main commands. I like hiram's idea of dropping the --
from them like svn and cvs do. I don't see why you have extra
restrictions on install. Actually, why not just drop install since it
is just deploy?
> --module module to install or deploy
>
> --plan deployment plan for module to install or deploy
These are the most common options and should be shortened and
simplified. For example the tool really requires one or two files when
installing, a jar file and an xml file. You can determine which one is
which, by simply looking at the magic number of each file.
> --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.
+1
>
> --modulelist a list of TargetModuleID names to start, stop, or
> undeploy
>
> --list-modules gives you a list of modules available from the
> management server you connected to. defaults
> to all targets, or use --targets
What is the difference between these two?
>
> --help this list
+1
> --list-targets gives you a list of targets available from the
> management server you connected to
>
> --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.
These are almost never going to be used, so should be documented as such
> --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
Options of creating an output Jar... these are rarely used and should
be documented as such.
> --driver JAR of the server driver, if not already on classpath.
> only necessary when non-Geronimo server targeted
I don't think there is any reason for us to support other app servers
drivers. This is a tool by geronimo for geronimo. Let the ide vendors
come up with the universal adapter.
So I see the following as being the most common usage:
deployer deploy funk.war
deployer undeploy funk
-dain
Re: Please Vote: 1 deployment tool or 2?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <am...@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
>
>
Re: Please Vote: 1 deployment tool or 2?
Posted by Davanum Srinivas <da...@gmail.com>.
[X] Add these features to the existing bin/deployer.jar tool
-- dims
On Wed, 27 Oct 2004 15:58:11 -0700, Dain Sundstrom
<ds...@gluecode.com> wrote:
> I want one tool, with a command line option to build online. I think
> it would be *extremely* confusing to have two tools to "deploy".
>
> -dain
>
> On Oct 25, 2004, at 7:44 PM, Aaron Mulder wrote:
>
> > I only got one vote on this, and it wasn't from a committer.
> > Please everyone take a look and send along your vote.
> >
> > Thanks,
> > Aaron
> >
> > ---------- Forwarded message ----------
> > Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
> > From: Aaron Mulder <am...@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
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Please Vote: 1 deployment tool or 2?
Posted by Dain Sundstrom <ds...@gluecode.com>.
I want one tool, with a command line option to build online. I think
it would be *extremely* confusing to have two tools to "deploy".
-dain
On Oct 25, 2004, at 7:44 PM, Aaron Mulder wrote:
> I only got one vote on this, and it wasn't from a committer.
> Please everyone take a look and send along your vote.
>
> Thanks,
> Aaron
>
> ---------- Forwarded message ----------
> Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
> From: Aaron Mulder <am...@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
Re: Please Vote: 1 deployment tool or 2?
Posted by David Jencks <da...@yahoo.com>.
At the moment I have a slight preference for 2 tools, mostly because I
can't imagine an implementation of one tool that didn't consist of 2
entirely separate implementations inside.
Being addicted to maven I doubt I would use either one very much:-)
thanks
david jencks
On Oct 25, 2004, at 7:44 PM, Aaron Mulder wrote:
> I only got one vote on this, and it wasn't from a committer.
> Please everyone take a look and send along your vote.
>
> Thanks,
> Aaron
>
> ---------- Forwarded message ----------
> Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
> From: Aaron Mulder <am...@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
>
Re: Please Vote: 1 deployment tool or 2?
Posted by Dain Sundstrom <ds...@gluecode.com>.
Aaron,
I don't think you have concisely explained what you want to do that is
different from the status quo, and this is why no one is rallying
around your proposal.
Also this "vote" is in the form of a poll (select from choices) instead
of a vote (+1/-1 for a specific idea).
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Oct 25, 2004, at 7:44 PM, Aaron Mulder wrote:
> I only got one vote on this, and it wasn't from a committer.
> Please everyone take a look and send along your vote.
>
> Thanks,
> Aaron
>
> ---------- Forwarded message ----------
> Date: Sat, 23 Oct 2004 14:46:41 -0400 (EDT)
> From: Aaron Mulder <am...@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
Re: Please Vote: 1 deployment tool or 2?
Posted by Jeremy Boynes <jb...@gluecode.com>.
2 simple tools rather than one complex one.
--
Jeremy