geronimo-user mailing list archives

We could leave the redeploy command there and just remove the
documentation for it, and make the deploy command do both. Maybe the
redeploy could print a nag to the console saying it's deprecated.
That way nothing would break for now.
Thanks,
Aaron
On 3/24/06, John Sisson <jrsisson@gmail.com> 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
> >
> >
>
>