+1 make the default development case easier! If want it to be explicit, then make that use a more verbose form.. "deploy --strict" or something like that. I guess you can always assume that a redeploy is strict (fail if not there) since the user would have used deploy to get a redeploy.
On 3/24/06, Aaron Mulder <[EMAIL PROTECTED]> 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 > -- Regards, Hiram
