dev@glassfish.java.net

Re: V3 redeploy does not work

From: Vince Kraemer <Vince.Kraemer_at_Sun.COM>
Date: Thu, 13 Mar 2008 11:25:44 -0700

I share Ludo's desire for having a command that does redeployment....
but my reasoning is based on the effect on users of the cli (and the
admin gui) [and even server integration plugins for NetBeans, Eclipse,
Cargo, etc. etc. etc.]

While current the 'deploy' command is overloaded to simulate
redeployment, it requires that the user re-enter data that may be
unnecessary. When users have to reenter data that is not necessary, we
have made it more likely that they will make a mistake... and have to
try again to enter the data correctly.

We can do better... AND were doing better in v3 until recently... that
is part of the reason I have been following up on this.

I will be honest... I do not care what the name of the command is... I
am more concerned about the operand... can we make the operand shorter
and less likely to enter incorrectly...

That can increase the usability of the CLI. Th GUI would ALSO be able
to leverage this, since the "redeploy" link for a directory deployed app
would be a SINGLE CLICK... with no stop on an intermediate "wizard"
page... (Note: that enhancement [single click redeploy of directory
deployed modules and apps] should be possible WITHOUT any user visible
redeploy command in the CLI... I filed
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4419 to capture
this request).

vbk

Ludovic Champenois wrote:
> 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
>>