Hi, Ludo
>> A few of us have been discussing some issues with deployment recently
>> and
>> I'd like to let everyone know what we ended up with and get your
>> feedback.
>
> To add to this thread:
> Both NetBeans and Eclipse are calculating this "redeploy or not"
> option based on the JSR 88 semantic:
> before doing a simple "run" action, the IDEs are asking for the list
> of deployed apps (via 88) and this returns a list of names.
> If the current desired name is there, a redeploy is emitted, if not, a
> deploy is emitted.
>
> A NetBeans "deploy" command (project popup menu) is in fact a
> "undeploy then deploy" while the "run" action is an optimal/minimal
> action:
> does nothing if nothing needs to happen (i.e a jsp file change), a
> deploy of the first time, and a redeploy if not, then the contextroot
> page is shown in the browser.
>
> Now the IDEs offer limited "name" control. This name is currently
> calculated based on the directory name where the project is, with
> space chars removed.
So the NB caculates the name from directory name and then use that name
as the name option to send the deployment request?
In EE 6, application name (or module name in standalone module case)
could be defined in the deployment descriptor. So in the case where user
defines an application name in application.xml, that name will not be
used as the application name if deployed through NB?
- Hong
>>
>> We have three ways to deploy an application using the command line and
>> two cases to consider for each operation.
>>
>> Here's what we came up with:
>>
>> | foo does not exist | foo exists
>> ------------------------------------------------------------
>> deploy foo.war | + | X
>> deploy --force foo.war | + | + [2]
>> redeploy foo.war | + [1] | +
>>
>>
>> Possible outcomes:
>>
>> X - command fails
>> + - command succeeds, app "foo" is deployed
>>
>> There were two changes we considered:
>>
>> 1. Should redeploying an app that isn't deployed be an error? Is it
>> likely
>> that you made a mistake if you try to redeploy something that isn't
>> deployed to begin with? If you don't care whether or not it's
>> already
>> deployed why not use deploy --force?
>>
>> 2. Should deploy --force with an app that's already deployed cause the
>> app to be deployed under a different name? The Java EE spec allows
>> (but does not require) the deployment tool to choose a different name
>> for the app if the name conflicts with an already deployed
>> application.
>> Does --force really mean "replace this app if it's already there", or
>> does it mean "deploy this new app no matter what, without disturbing
>> other apps that might be deployed"?
>>
>> Either of these changes would cause redeploy and deploy --force to
>> behave
>> differently. We were worried about the compatibility impact of such
>> a change,
>> both with v2 (for which deploy is already incompatible because
>> --force is
>> the default in v2), and with v3 where people have come to expect
>> these two
>> commands to behave the same.
>>
>> If anyone feels strongly that we should make either of these changes,
>> let me know.
>>
>> Thanks.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>