I think we are overthinking this issue. I can't remember a single
time I deployed something and didn't want the a currently installed
version redeployed. I say just alias redeploy to deploy. If people
want to write specific scripts for deploy they can always use the
"distribute" and "start" primitives.
-dain
On Mar 25, 2006, at 5:40 AM, Hernan Cunico wrote:
I think we all agree that the easier for the user the better.
Having one deploy command smart enough to deploy or redeploy based
on the current status would be cool as Aaron suggested. I think it
would also be nice, if the command is going to redeploy a running
app, to have a confirmation message like "... App XYZ already
running, redeploy? [Y/N]", whis this said, a new flag to the
command should be added to force a response to that command.
As for support, what is the plan for start server commands? I think
there are currently too many options. Can we list the supported, or
preferred, commands? and for those are are not "preferred" could we
print a message "command no longer supported, use XYZ instead" when
you execute it.
Cheers!
Hernan
John Sisson wrote:
Agree that would make it easier for the user.
Are you thinking of supporting the old commands for users with
existing deployment bat/sh scripts for their apps or will the
redeploy command be unsupported and documented as a migration
task in the release notes?
Does anyone know if there is a way to have a JIRA flagged as
having a migration impact, so we can group those together or flag
them in the release notes?
John
Aaron Mulder wrote:
Currently if you use the command-line deploy tool, you have to
specify
different deploy commands depending on whether the module is already
deployed. That is, you use "deploy" the first time, and "redeploy"
thereafter:
java -jar bin/deployer.jar deploy foo.war
java -jar bin/deployer.jar deploy foo.war <-- fails, already
deployed
java -jar bin/deployer.jar redeploy foo.war
java -jar bin/deployer.jar undeploy foo.war
java -jar bin/deployer.jar redeploy foo.war <-- fails, not
deployed
After using this a bit, I'd lean toward combining these into one
command where the deploy tool will deploy the app if it's not
already
running, and redeploy it if it is already running.
Any objections to that? I wonder if there are real-world cases
where
you'd rather get the error if the deployment state isn't what you'd
expect. On the other hand, that seems seriously outweighed by the
number of times I up-arrow and repeat the previous command and it
gives an error because it's already deployed or whatever. At this
point, I think making things easier during development ought to
be the
higher priority.
Thanks,
Aaron
