On 12/04/2013 03:15 PM, ssilvert(a)redhat.com wrote:
On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
> I haven't thought about that scope. But anyway, if it proves useful
> it's doable.
The use case I had in mind was for if I want to share a script that runs
against servers or domain controllers on the network. As it is, I would
have to tell the other person how to set all their variables. Giving
the other person my .jbossclirc file is not a good idea because it also
contains variable values that only pertain to my local environment.
Variables can also be set in the beginning of a script. Although, I can
see advantages of keeping them out and simply relying on certain
variables in a script.
It's the same concept as Maven's settings.xml file for local
properties
vs. the "shared" properties set in pom.xml.
It might be that all you need is to simply allow a variable to refer to
system properties on the server. That would be your shared variable.
The $prod_db example you gave earlier would be a good candidate for a
shared variable. So someone sets the property with:
/system-property=prod_db/:add(value=mydatabase)
Then anyone could use the $prod_db variable against that server no
matter where the command runs from.
That is indeed useful. BTW, don't we have aliases in the management
model that could also be used for this?
Alexey