3:46 a.m.
The deployment terms are really messed up in the CLI.
I.e. the command is named "deploy <foo.bar>", but at the same time an
operation exists on the deployment to "deploy" (aka enable) it:
[domain@localhost:9999 /] deploy ~/Desktop/test-application.war --all-server-groups
[domain@localhost:9999 /]
/server-group=main-server-group/deployment=test-application.war:deploy
I would suggest we align these terms with WIKI page:
http://community.jboss.org/wiki/AS7DeploymentTerms
This would mean to rename the command to "upload" and the operation to
"enable".
Whatever we chose, we need to remove the ambiguity.
Ike
6:18 a.m.
Just re-naming the current deploy command to upload doesn't sound nice
to me.
Because the command actually deploys the package (unless you add
--disabled). So, it's as clear as it can be.
Renaming just to match an operation name doesn't justify it for me in
this case. It may also do a full-replace if --force is specified, btw.
So, if we were to re-name the command we would have to review the
arguments too.
Would 'upload' enable by default? Or it would only if --enable is
specified (with server groups in the domain mode)?
Should enable be a separate command? Which would accept server groups,
etc? This would mean two commands instead of one to actually deploy an app.
What would "undeploy" be renamed to? "remove" seems to be too general.
unload? remove-deployment?
Alexey
On 06/22/2011 10:46 AM, Heiko Braun wrote:
The deployment terms are really messed up in the CLI.
I.e. the command is named "deploy <foo.bar>", but at the same time an
operation exists on the deployment to "deploy" (aka enable) it:
[domain@localhost:9999 /] deploy ~/Desktop/test-application.war --all-server-groups
[domain@localhost:9999 /]
/server-group=main-server-group/deployment=test-application.war:deploy
I would suggest we align these terms with WIKI page:
http://community.jboss.org/wiki/AS7DeploymentTerms
This would mean to rename the command to "upload" and the operation to
"enable".
Whatever we chose, we need to remove the ambiguity.
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:47 a.m.
I wouldn't mind if the command stays the way it is.
But then the operation name on a deployment needs to be changed.
For instance to :enable and :disable opposed to :deploy, because that already
taken by the command name.
It would make sense, because the deployment carries and attribute name "enabled"
already.
If just look at the CLI on it's it makes perfect sense they way you build it.
But if regards the operation, the CLI commands, and the model description
you will realize that all three diverged at some point and rely on their own specific
terms.
Ike
On Jun 22, 2011, at 1:18 PM, Alexey Loubyansky wrote:
Just re-naming the current deploy command to upload doesn't sound
nice
to me.
Because the command actually deploys the package (unless you add
--disabled). So, it's as clear as it can be.
Renaming just to match an operation name doesn't justify it for me in
this case. It may also do a full-replace if --force is specified, btw.
So, if we were to re-name the command we would have to review the
arguments too.
Would 'upload' enable by default? Or it would only if --enable is
specified (with server groups in the domain mode)?
Should enable be a separate command? Which would accept server groups,
etc? This would mean two commands instead of one to actually deploy an app.
What would "undeploy" be renamed to? "remove" seems to be too
general.
unload? remove-deployment?
Alexey
6:51 a.m.
sometimes my keyboard eats whole words.
sorry, it's excited due to the upcoming as7 release.
Ike
On Jun 22, 2011, at 1:47 PM, Heiko Braun wrote:
I wouldn't mind if the command stays the way it is.
But then the operation name on a deployment needs to be changed.
For instance to :enable and :disable opposed to :deploy, because that already
taken by the command name.
It would make sense, because the deployment carries and attribute name
"enabled" already.
If just look at the CLI on it's it makes perfect sense they way you build it.
But if regards the operation, the CLI commands, and the model description
you will realize that all three diverged at some point and rely on their own specific
terms.
Ike
On Jun 22, 2011, at 1:18 PM, Alexey Loubyansky wrote:
> Just re-naming the current deploy command to upload doesn't sound nice
> to me.
> Because the command actually deploys the package (unless you add
> --disabled). So, it's as clear as it can be.
>
> Renaming just to match an operation name doesn't justify it for me in
> this case. It may also do a full-replace if --force is specified, btw.
>
> So, if we were to re-name the command we would have to review the
> arguments too.
> Would 'upload' enable by default? Or it would only if --enable is
> specified (with server groups in the domain mode)?
> Should enable be a separate command? Which would accept server groups,
> etc? This would mean two commands instead of one to actually deploy an app.
>
> What would "undeploy" be renamed to? "remove" seems to be too
general.
> unload? remove-deployment?
>
> Alexey
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:58 a.m.
On 06/22/2011 01:47 PM, Heiko Braun wrote:
I wouldn't mind if the command stays the way it is.
But then the operation name on a deployment needs to be changed.
For instance to :enable and :disable opposed to :deploy, because that already
taken by the command name.
It would make sense, because the deployment carries and attribute name
"enabled" already.
This makes sense. And probably will be consistent with other things.
E.g. data sources chose enable/disable as names.
If just look at the CLI on it's it makes perfect sense they way
you build it.
But if regards the operation, the CLI commands, and the model description
you will realize that all three diverged at some point and rely on their own specific
terms.
Agreed, they should be aligned where possible. Although there will still
be some differences, since higher level commands might translate into
different operations (including composite) depending on the conditions
and arguments.
The new approach to commands I am working on right now will help with this.
Alexey
Ike
On Jun 22, 2011, at 1:18 PM, Alexey Loubyansky wrote:
> Just re-naming the current deploy command to upload doesn't sound nice
> to me.
> Because the command actually deploys the package (unless you add
> --disabled). So, it's as clear as it can be.
>
> Renaming just to match an operation name doesn't justify it for me in
> this case. It may also do a full-replace if --force is specified, btw.
>
> So, if we were to re-name the command we would have to review the
> arguments too.
> Would 'upload' enable by default? Or it would only if --enable is
> specified (with server groups in the domain mode)?
> Should enable be a separate command? Which would accept server groups,
> etc? This would mean two commands instead of one to actually deploy an app.
>
> What would "undeploy" be renamed to? "remove" seems to be too
general.
> unload? remove-deployment?
>
> Alexey
8:19 a.m.
Quoting Alexey Loubyansky <alexey.loubyansky(a)redhat.com>:
Just re-naming the current deploy command to upload doesn't sound
nice
to me.
Because the command actually deploys the package (unless you add
--disabled). So, it's as clear as it can be.
It actually doesn't deploy the package. It only sets up one or more
conditions that MIGHT cause the package to deploy. Even if you upload
the deployment and add it to all server groups and enable all in one
command, you might not get a deployed deployment. You still need at
least one running host on one of the server groups. So even in the
extreme case, a successful "deploy" command might not deploy anything.
I would suggest renaming it to "upload" or "add-content". For bonus
points, the command could try to see if the deployment actually
started and report that condition back to the user.
Renaming just to match an operation name doesn't justify it for me in
this case. It may also do a full-replace if --force is specified, btw.
Agreed. We have to be careful with naming meta-commands.
So, if we were to re-name the command we would have to review the
arguments too.
Would 'upload' enable by default? Or it would only if --enable is
specified (with server groups in the domain mode)?
I think it should not enable by default. Enable-by-default is
convenient for development, but in production you want to be careful
about when something goes live.
Should enable be a separate command? Which would accept server
groups,
etc? This would mean two commands instead of one to actually deploy an app.
I'd say have both. Enable/Disable commands would be convenient. I'm
thinking especially when you want to upload, set up some other things
like datasources, then enable.
What would "undeploy" be renamed to? "remove" seems to be too
general.
unload? remove-deployment?
remove-deployment sounds good.
Alexey
On 06/22/2011 10:46 AM, Heiko Braun wrote:
>
>
> The deployment terms are really messed up in the CLI.
> I.e. the command is named "deploy <foo.bar>", but at the same time
an
> operation exists on the deployment to "deploy" (aka enable) it:
>
> [domain@localhost:9999 /] deploy ~/Desktop/test-application.war
> --all-server-groups
>
>
> [domain@localhost:9999 /]
> /server-group=main-server-group/deployment=test-application.war:deploy
>
>
> I would suggest we align these terms with WIKI page:
> http://community.jboss.org/wiki/AS7DeploymentTerms
>
> This would mean to rename the command to "upload" and the operation to
> "enable".
> Whatever we chose, we need to remove the ambiguity.
>
> Ike
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:33 a.m.
On 06/22/2011 03:19 PM, ssilvert(a)redhat.com wrote:
Quoting Alexey Loubyansky<alexey.loubyansky(a)redhat.com>:
>
> So, if we were to re-name the command we would have to review the
> arguments too.
> Would 'upload' enable by default? Or it would only if --enable is
> specified (with server groups in the domain mode)?
I think it should not enable by default. Enable-by-default is
convenient for development, but in production you want to be careful
about when something goes live.
> Should enable be a separate command? Which would accept server groups,
> etc? This would mean two commands instead of one to actually deploy an app.
I'd say have both. Enable/Disable commands would be convenient. I'm
thinking especially when you want to upload, set up some other things
like datasources, then enable.
Following what I'm doing now I might end up with
deployment add file_path
deployment deployment_name deploy
deployment deployment_name undeploy
> What would "undeploy" be renamed to? "remove"
seems to be too general.
> unload? remove-deployment?
remove-deployment sounds good.
Why not then add-deployment instead of upload?
Thanks,
Alexey
8:48 a.m.
Quoting Alexey Loubyansky <alexey.loubyansky(a)redhat.com>:
On 06/22/2011 03:19 PM, ssilvert(a)redhat.com wrote:
> Quoting Alexey Loubyansky<alexey.loubyansky(a)redhat.com>:
>>
>> So, if we were to re-name the command we would have to review the
>> arguments too.
>> Would 'upload' enable by default? Or it would only if --enable is
>> specified (with server groups in the domain mode)?
>
> I think it should not enable by default. Enable-by-default is
> convenient for development, but in production you want to be careful
> about when something goes live.
>
>> Should enable be a separate command? Which would accept server groups,
>> etc? This would mean two commands instead of one to actually deploy an app.
>
> I'd say have both. Enable/Disable commands would be convenient. I'm
> thinking especially when you want to upload, set up some other things
> like datasources, then enable.
Following what I'm doing now I might end up with
deployment add file_path
deployment deployment_name deploy
deployment deployment_name undeploy
I like it.
>> What would "undeploy" be renamed to? "remove" seems to be too
general.
>> unload? remove-deployment?
>
> remove-deployment sounds good.
Why not then add-deployment instead of upload?
Or to be consistent with what you have above:
deployment deployment_name remove
deployment deployment_name server_group assign
deployment deployment_name server_group unassign
Thanks,
Alexey
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
10:52 a.m.
On 6/22/11 6:58 AM, Alexey Loubyansky wrote:
On 06/22/2011 01:47 PM, Heiko Braun wrote:
>
>
> I wouldn't mind if the command stays the way it is.
> But then the operation name on a deployment needs to be changed.
> For instance to :enable and :disable opposed to :deploy, because that already
> taken by the command name.
>
> It would make sense, because the deployment carries and attribute name
"enabled" already.
This makes sense. And probably will be consistent with other things.
E.g. data sources chose enable/disable as names.
I can register "enable" and "disable" commands easily enough. I assume
"deploy" and "undeploy" have to stay for CR1 as it will break the
console otherwise.
> If just look at the CLI on it's it makes perfect sense they
way you build it.
> But if regards the operation, the CLI commands, and the model description
> you will realize that all three diverged at some point and rely on their own specific
terms.
Agreed, they should be aligned where possible. Although there will still
be some differences, since higher level commands might translate into
different operations (including composite) depending on the conditions
and arguments.
The new approach to commands I am working on right now will help with this.
Alexey
>
> Ike
>
>
> On Jun 22, 2011, at 1:18 PM, Alexey Loubyansky wrote:
>
>> Just re-naming the current deploy command to upload doesn't sound nice
>> to me.
>> Because the command actually deploys the package (unless you add
>> --disabled). So, it's as clear as it can be.
>>
>> Renaming just to match an operation name doesn't justify it for me in
>> this case. It may also do a full-replace if --force is specified, btw.
>>
>> So, if we were to re-name the command we would have to review the
>> arguments too.
>> Would 'upload' enable by default? Or it would only if --enable is
>> specified (with server groups in the domain mode)?
>> Should enable be a separate command? Which would accept server groups,
>> etc? This would mean two commands instead of one to actually deploy an app.
>>
>> What would "undeploy" be renamed to? "remove" seems to be too
general.
>> unload? remove-deployment?
>>
>> Alexey
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:07 a.m.
This direction sounds nice. We're going to have to be cautious about
breaking the existing high-level CLI commands in 7.1 though.
On 6/22/11 8:48 AM, ssilvert(a)redhat.com wrote:
Quoting Alexey Loubyansky<alexey.loubyansky(a)redhat.com>:
> On 06/22/2011 03:19 PM, ssilvert(a)redhat.com wrote:
>> Quoting Alexey Loubyansky<alexey.loubyansky(a)redhat.com>:
>>>
>>> So, if we were to re-name the command we would have to review the
>>> arguments too.
>>> Would 'upload' enable by default? Or it would only if --enable is
>>> specified (with server groups in the domain mode)?
>>
>> I think it should not enable by default. Enable-by-default is
>> convenient for development, but in production you want to be careful
>> about when something goes live.
>>
>>> Should enable be a separate command? Which would accept server groups,
>>> etc? This would mean two commands instead of one to actually deploy an app.
>>
>> I'd say have both. Enable/Disable commands would be convenient. I'm
>> thinking especially when you want to upload, set up some other things
>> like datasources, then enable.
>
> Following what I'm doing now I might end up with
>
> deployment add file_path
> deployment deployment_name deploy
> deployment deployment_name undeploy
I like it.
>
>>> What would "undeploy" be renamed to? "remove" seems to be
too general.
>>> unload? remove-deployment?
>>
>> remove-deployment sounds good.
>
> Why not then add-deployment instead of upload?
Or to be consistent with what you have above:
deployment deployment_name remove
deployment deployment_name server_group assign
deployment deployment_name server_group unassign
>
> Thanks,
> Alexey
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4694
days inactive
4694
days old
9 comments
4 participants
participants (4)
-
Alexey Loubyansky -
Brian Stansberry -
Heiko Braun -
ssilvert＠redhat.com