Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.3)
In-Reply-To: <4425485E.6030605@gmail.com>
References: <74e15baa0603241654g5180f277ob443c193dcc62208@mail.gmail.com>
 <4424A32F.9020706@gmail.com> <4425485E.6030605@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4250317C-7D78-44EB-8D45-8F81E3C2F000@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Deploy Tool: deploy vs redeploy
Date: Tue, 28 Mar 2006 12:36:18 -0800
To: user@geronimo.apache.org

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
>>>
>>>