vince kraemer wrote:
> Kedar Mhaswade wrote:
>> vince kraemer wrote:
>>> Kedar Mhaswade wrote:
> [snip]
>>> That is a great catch. So, now we just need to figure out a way to
>>> make it easy for the user to disambiguate their intent, without
>>> requiring that they reenter a full path every time they want to
>>> redeploy something.
>>
>> Hmmm. But I am unsure how this happens with just the name alone.
>>
>> e.g.
>> - asadmin deploy --name bar foo.war
>> - asadmin redeploy bar
>>
>> will not execute because server does not know what to redeploy!
>>
>> Perhaps you're thinking only in terms of directory deployment.
>
> You are right again. I was thinking of directory deployment, which is
> the most useful deployment strategy for developers.
>
>>
>> In order to best disambiguate, for deployment or redeployment purpose,
>> provide
>> the correct data -- either the war file or the folder where it
>> resides. It might
>> be a little clumsy that you have to provide the path to the directory,
>> but it is
>> very clear.
>
> That approach is one way to handle the redeploy of directory deployed
> modules or applications.
>
> Do all users need to pay a penalty for a worst-case scenario?
>
> Or, can we develop a solution that minimizes the worst-case scenario and
> minimizes the redundant data entry that is necessary?
You know Vince, I don't know. As a user, I was content with what V2 does,
but it is obvious that I have a bias. But I have seen users do autodeployment,
which I presume needs a war file to be "dropped" in a designated folder.
Another important (and often forgotten)
aspect of "asadmin" deployment is its "remotability". You can
be on your laptop and deploying to your "development server", which has no
shared file system with your laptop. In that case, directory deployment is
not useful. Number of such "developers" is growing (so I am told) and for them
.war is a requirement, which they aren't that annoyed with.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>