Kedar Mhaswade wrote:
> I thought that the plan of record is till we find the correct default
> value
> for --force, it remains true. This was after ccc meeting yesterday.
>
> Thus, asadmin deploy foo.war [foodir] followed by asadmin deploy foo.war
> [foodir] should result in redeployment of the underlying
> application/module.
>
> This means, we should not use "redeploy" command just yet, as "deploy
> over deploy" is supposed to achieve the same effect.
>
> I am not convinced we ought to have a "redeploy" command.
JSR 88 has it in in semantics.
NB and Eclipse plugins rely on a 'redeploy' feature, (nb uses 88 and
extends it for dir deploy).
NB does not make it easy at all to access the app location for redeploy
(see the 88 APIs for that, using only TMID)
So I am convinced, based on my experience on Tools integration.
I hope I clarified your doubts there. I am not talking about asadmin CLI
tools, I am talking about API/commands used by Tools like NB 4.1, 5.0,
5.5, 6.0, 6.0.1 and 6.1 beta or Eclipse 3.2, 3.3 and future.
It was working nice in Nb V3 plugin for TP1.
Since TP1 I could not see a single V3 build which is working nicely with
Tools.
I would suggest the entire Deploy/Admin team to use NetBeans or/and
Eclipse as a sanity test before doing any changes in deployment area.
This way, we could all do a synchronous check in so that this
combination is always working.
If you are not convinced yet, remember that the biggest download numbers
we have for GF v2 are coming from Tools/Runtime bundles:-)
Cheers,
Ludo
>
> Jerome, Bill, please help clarify doubts here.
>
> - Kedar
>
> Vince Kraemer wrote:
>> This is good news. I am happy that this useful command is getting a
>> second chance.... for users sake.
>>
>> The v3 plugin code could be changed to work with just about
>> anything. It isn't pleasant, but it is do-able.
>>
>> Forcing users to go back to a poorer interface, after a better one
>> has been identified and implemented, is.... more than unpleasant.
>>
>> vbk
>>
>> Hong Zhang wrote:
>>> Hi, Vince
>>>
>>>> I disagree with your analysis.
>>>>
>>>> I think that whether by luck or deep analysis, Jerome made the
>>>> right decisions concerning the need for a redeploy "command".
>>>>
>>>> Eliminating it for 'ease of maintenance' is not a compelling
>>>> justification.... especially when there was a working
>>>> implementation that was in-place....
>>>
>>> When we made the decision, we were not aware of that the NetBeans
>>> plug in was using the new redeploy command. And I guess we did not
>>> realize the parameter differences of the new redeploy command vs the
>>> old "deploy --force". In any case, we will restore the old syntax
>>> of redeploy command and the changes should be checked in soon.
>>>
>>> - Hong
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>