geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <>
Subject Re: Deploy Tool: deploy vs redeploy
Date Sat, 25 Mar 2006 13:40:46 GMT
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
cool as Aaron suggested. I think it would also be nice, if the command is going to redeploy
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
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.


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

View raw message