I have configured a Modeshape workspace on my dev box using XML, pointing to:
workspaceRootPath="C:/jcr/modeshape/dev/..."
I will deploy to Linux with a workspace mounted on a different volume:
workspaceRootPath="/jcr/modeshape/prod/..."
Is it possible to use an environment variable to configure this or do I need to resort to programmatic configuration? Is there an approach recommended by the Modeshape team?
Thanks
If you're using later versions of ModeShape, you can use a variable in the configuration file that will be replaced at configuration load time with the value of the System property of the same name. For example, if you use the following:
workspaceRootPath="${myWorkspaceDirectory}"
and have a System property "myWorkspaceDirectory" set to "/foo/bar", then when ModeShape loads the configuration it will resolve the variable into the equivalent:
workspaceRootPath="/foo/bar"
Of course, the variable can be just a part of the attribute value, and you can even use multiple variables (as long as they're not nested). For example, this is valid, too:
workspaceRootPath="${my.system.root.path}/modeshape/${my.system.deploymentType}"
Finally, the grammar of each variable is:
"${" systemPropName { "," systemPropName } [ ":" defaultValue ] "}"
This allows 1 or more System property names and an optional default value to be specified within a single variable. The System property names are evaluated from left to right, and the first to have a corresponding real system property will be used. Here's another contrived example:
workspaceRootPath="${my.system.path1,my.system.path2,my.system.path3:/default/path}/modeshape/${my.system.deploymentType}"
Related
In my project, the CMakeLists includes other cmake files from a library and those dependencies need some cache variables to be configured by user values.
It is all working well if I define those values from the command line with the cmake command:
-DTHIRDPARTY_FRAMEWORK_ROOT="$thirdpartyFrameworkPath"
But can I define (= hardcode) such values in my own CMakeLists file?
To avoid my own users to do it when they configure my project (some values of the 3d party configuration are constant in my project), and make my own cmake interface simpler.
I tried to simply set the variable with a value, but it is both defined and used in the included cmake so it gets overwritten with their default value just before being used.
Using set(... FORCE) seems to work but it does not look clean to me, and might lead to confusing errors if they rename or change the type of the variables on their side. It also forces me to add a type and a doc string because of the set(... CACHE ...) syntax.
Is there a better way to do this?
Setting CACHE INTERNAL variable is a proper way for hardcode a parameter of the inner project in the outer one:
set(THIRDPARTY_FRAMEWORK_ROOT CACHE INTERNAL "Hardcoded root for 'thirdparty'" <value>)
INTERNAL type makes sure that this setting will overwrite the option (FORCE doesn't need) and makes sure that the option won't be shown for a "normal" user.
Since the parameter is not intended to be changed by a user, its real type is meaningless, so there is no needs for it to coincide with the one set in the inner project.
As for description, you could set it to be empty (the parameter is not shown to the normal user, remember?). Alternatively, in the description you could explain why do you set the variable in the outer project. So an "advanced" user will see your description.
Scenario: to have multiple Kubernetes deployments I have a skeleton.tf file that could create an app as per requirement with minimum variable changes and in different namespaces and I do not want to provide a default name so that I will give the input everytime I do a Terraform plan and apply
like
resource "kubernetes_deployment" "${var.deployment-1}" {
...
...
namespace= var.namespace_1
...
}
how do I achieve this? Is this supported, because I face a syntax interpolation error,
or
Invalid string literal: Template sequences are not allowed in this string. To include a literal "$", double it (as "$$") to escape it.
or
Invalid character: This character is not used within the language.
or
Invalid block definition: Either a quoted string block label or an opening brace ("{") is expected here.
I have read about the terraform workspaces but then, it would be a tedious task to be able to get the resource name as a dynamic input. any help or workarounds to this is appreciated.
The name given in the second label of a resource block is used only within the current Terraform module, so there is no need for it to be dynamically customizable. If you don't have a specific name to use then you can use a generic name like "main".
Because this is a Terraform-only name, Terraform will automatically deal with it appearing in possibly several different instances of your module, because the full address of a resource includes the address of the module that contains it. The whole result is therefore unique with in a Terraform configuration, and the resource's local name is unique within the module that declares it.
I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml
I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.
below code snippet not working
<property name="environment" value="${env.GAH_ENV}"/>
The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's #ConfigProperty.
The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.
In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.
But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via #Inject #ConfigProperty.
By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).
But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).
This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.
I am using CMake 3.10.2 in Windows.
When I set the variable using CACHE like this
SET(ABAQUS_MAJORVERSION 2016)
SET(ABAQUS_MAJORVERSION ${ABAQUS_MAJORVERSION} CACHE STRING "" )
When I change the ABAQUS_MAJORVERSION variable to 2014 in GUI, this change is not updated in CMake. It keeps generating for 2016 version.
Please help in this regard.
Thanks in Advance
Edit1:
This is the project structure:
|CMakeLists.txt
|FindABAQUS.cmake
|-project1
|---source1.cpp
|---CMakeLists.txt which has SET(ABAQUS_MAJORVERSION 2016 CACHE STRING "")
|-project2
|---source2.cpp
|---CMakeLists.txt which has SET(ABAQUS_MAJORVERSION 2016 CACHE STRING "")
I changed the ABAQUS_MAJORVERSION to 2014 in GUI. The ABAQUS_MAJORVERSION became 2014 in CMakeCache.txt file.
But when printed with message(${ABAQUS_MAJORVERSION }) it shows 2016
Solution:
example: SET(MAJORVERSION 2016 CACHE STRING "")
One might need to unset all the Include paths and library paths, to take effect of the new version Include path and library paths.
example: UNSET(INCLUDE_PATH CACHE)
UNSET(LIBRARY_PATH CACHE)
It may depend on how you're using (or accidentally not using) the cache variable. You can have a normal variable and cache variable of the same name existing at the same time (which is exactly what you have going on) and still access them both (as per the docs on variable references) using ${var_name} for the regular variable, and $CACHE{var_name} for the cache variable.
This can trip people up because they aren't used to writing the explicit cache form, because usually the following behaviour takes effect:
When evaluating Variable References, CMake first searches the function call stack, if any, for a binding and then falls back to the binding in the current directory scope, if any. If a "set" binding is found, its value is used. If an "unset" binding is found, or no binding is found, CMake then searches for a cache entry. If a cache entry is found, its value is used. Otherwise, the variable reference evaluates to an empty string. The $CACHE{VAR} syntax can be used to do direct cache entry lookups.
I'm guessing this is what's tripping you up.
The following scenario can be another cause of confusion for anyone not aware of its behaviour, but I don't think it's what's tripping you up here.
In the CMake docs for setting cache variables:
Since cache entries are meant to provide user-settable values this does not overwrite existing cache entries by default. Use the FORCE option to overwrite existing entries.
For example, cache variables can be set on the command line with -D var_name:TYPE=VALUE.
I want to ask is it possible to have database properties outside of any property file now I have database properties inside dbconfig.properties but I want to have it be supplied from outside passing as an argument for example.
Is there any suggestion to have this approach.
I would follow the documentation:
24.2 Accessing command line properties:
By default SpringApplication will convert any command line option
arguments (starting with ‘--’, e.g. --server.port=9000) to a property
and add it to the Spring Environment. As mentioned above, command line
properties always take precedence over other property sources.