geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Deploy Tool: deploy vs redeploy
Date Tue, 28 Mar 2006 20:36:18 GMT
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.


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

View raw message