On 12/4/2013 7:41 AM, Alexey Loubyansky wrote:
I haven't thought about that scope. But anyway, if it proves
The use case I had in mind was for if I want to share a script
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.
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:
Then anyone could use the $prod_db variable against that server no
matter where the command runs from.
On 12/04/2013 09:19 AM, Heiko Braun wrote:
> +1 on sharing them.
> On 03 Dec 2013, at 15:27, ssilvert(a)redhat.com
> <mailto:firstname.lastname@example.org> wrote:
>> You would store the variables and values in the management
>> model so that they could be shared by any user, script, or process.
> wildfly-dev mailing list