Does any one have idea, what if i want to define path with some environment variable in fitnesse setup via content.txt.
At this moment we have content.txt checked in our repository containing the path variable of each and every developers environment. I want to resolve that problem by defining atleast a variable prefix with a standard path.
Current path definitions like below:
!path /home/xyz/workspace/blah/blah
Want to change it to something like
!path $workspace/blah/blah
I tried using !define workspace {this/is/my/path}
but it doesn't seems to be working and complains undefined variable workspace.
Use ${myvariable} to reference a variable.
Mike has pointed out that the way you referring variable is wrong. Here are some more details for those who get confused between ${variable} and $slimSymbol when first started using FitNesse.
${variable} is a concept on the Wiki page level . There are a few ways to define them:
using !define statement
properties in the plugins.properties file
using system variable passed when starting FitNesse Server
through url params
These variable will be translated at the time the page is visited. You can find some official documentation here
$slimSymbol on the other hand is a "runtime variable" used in SLiM test system. They are defined by using $slimSymbol= symtax in the test case, and the value will only be available in the runtime. Documentation here
Related
The current version of mule runtime we are using is 4.3.0. We have multiple environments where we have to set up the runtimes.
We want to define a variable in the runtime wrapper.conf and use that variable across multiple properties.
Tried to follow the tanukui software instructions "https://wrapper.tanukisoftware.com/doc/english/props-envvars.html"
set.default.ENV_BASE_PATH=/path/to/the/environment
wrapper.java.additional.22=-DMULE_LOG_DOMAIN_V2=%ENV_BASE_PATH%/logs/%WRAPPER_HOSTNAME%/DomainV2
WRAPPER_HOSTNAME is working which is a default variable that tanuki provides. But the custom variable "ENV_BASE_PATH" is not working.
when the runtime is comes up it is not taking "ENV_BASE_PATH" as a variable but taking it as an absolute value.
My recommendation is to just avoid using environment variables in the wrapper. Just replace it by the actual value. It doesn't look as good but it will work.
I am using IntelliJ to develop Java applications which uses YAML files for the app properties. These YAML files have some placeholder/template params like:
credentials:
clientId: ${client.id}
secretKey: ${secret.key}
My CI/CD pipeline takes care of substituting the actual value for these params (client.id and secret.key) based on the environment on which it is getting deployed.
I'm looking for something similar in IntelliJ. Something like, I configure some static/fixed values for the params (Ex: client.id and secret.key) within the IDE and when I run locally using the IDE, these values should be substituted onto these YAML files and run.
This will actually save me from updating the YAML files with the placeholder params each time I check in some other changes to my version control system.
There is no such feature in IDEA, because IDEA cannot auto detect every possible known or unknown expression language or template macros that you could use in a yaml file. Furthermore, IDEA must create a context for that or these template files.
For IDEA it's just a normal yaml file.
IDEA has a language injection feature.
That can be used to inject sql into a java string for instance or inject any language into a yaml field.
This is a really nice feature and can help you to rename sql column names aso. but this won't solve your special problem, because you want to make that template "runnable" within in certain context where you define your variables.
My suggestion would be, to write a small simple program that makes nearly the same as the template engine does.
When you only need simple string replacements and no macro execution then this could be done via regular expression.
If it's more complicated I would use the same template engine as the "real processor" does.
If you want further help, it would be good to know how your yaml processing pipeline looks like.
In Intellij IDEA 14, I've defined a Path Variable FOO (in Preferences). The IDEA docs are ambiguous about where these variables can be used... Can I reference FOO in a (Tomcat) Run Configuration > VM Options ie:
-DmyProp=$FOO$
Also is it $FOO$ or $FOO?
I know this question is 3 years old, but is still comes up in Google when one searches for solution to this problem, so I thought I should post the answer anyway.
It is possible to use Path Variables in Run Configurations (tested on IntelliJ 2018.1, should work the same on older versions) and here's how:
Use the variable in Your Run Configuration using syntax: -DmyProp=$FOO$
Restart IntelliJ or close and reopen the project.
When you reopen Your Run Configuration you should see: -DmyProp='the value of FOO'.
If you open the project files in a text editor, you will still see -DmyProp=$FOO$, however when the project is loaded IntelliJ automatically replaces it with the current value of the variable.
No you can't. This Variable are interpreted with a command processor like shell or windows batch.
On Unix it is $FOO on Win %FOO%.
You can create different Run Configurations with the $FOO replacements and save it.
Examples:
Config1: -DmyProp=blah1
Config2: -DmyProp=blah2
etc.
I try to use two external Fortran module which are in same name (in this case mod_param). So, when i try to compile my code, the compiler gives the following error,
mod_param.o: In function mod_param._':
mod_param.f90:(.text+0x0): multiple definition ofmod_param._'
mod_param.o:mod_param.F90:(.text+0x0): first defined here
is there any way to solve it without renaming the one of the module file and its name? I don't prefer the renaming because the external modules are maintained by someone else and i don't want to play with them. Is there any special use statement to do that?
No. It is necessary to change the function name in the source code in at least one of the modules.
Since the code is being maintained by someone else, consider automating the renaming: perhaps the project Makefile can run a sed script which changes the function names. So that the dependencies are clear, be sure to make the output of the sed script a new file name which is used to be compiled—the virgin module would have a filename which is not compiled or linked into the project.
Even if it were somehow possible to link them both in with the same name, how would you control which was called with the name?
According to F2003 standard module names are global entities and must be unique in a program, with some exteptions for intrinsic modules.
So, that would be a no (Besides, how would you tell them apart were they of the same name?)
What reasons could there be for the following strange behaviour, and how might I track down the issues?
We use a combination of make files and msbuild.
I have a project which needs to be strongly named. I was previously setting the snk to use in the project file like this:
<AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile>
where EnvironmentVariable was defined in the batch file that launched the shell for the build like this:
set EnvironmentVariable='SomePath'
and this worked ok. Now I need the string name key to be able to be changed, so it can be different on the dev machine and the release build server. There is a variable which exists to hold the full path to the strong name key file, called StrongNameKeyFile. This is defined in the msbuild environment, and if I put some text output in the targets or properties files that are included as part of the msbuild task which build the project then I can see that this StrongNameKeyFile points to the correct location. So I changed the csproj to have this instead:
<AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>
but when I try and compile this is evaluating to empty and no /keyfile is specified during the build.
We also have variable defined in the make files and these can be accessed in the csproj as well. These are used to point to the locations of referenced dlls, so that they can be different on dev and build machines. I know that these are set as the references come out correctly and everything compiles, but if I try and use one of these variables in the AssemblyOriginatorKeyFile element then it evaluates to empty in that element, but works in the reference element.
Why might this be? Is AssemblyOriginatorKeyFile treated specially somehow? How can I go about tracking the cause of this down?
There's no good reason why this should happen - as you know it normally Just Works; it's likely to be something in the chain dropping it on the floor.
One thing to try is explicitly passing it via /p:StrongNameKeyFile=XX - that would eliminate environment variables and the correct propagation thereof from your inquiries.
Another potential thing is that something is clobbering the variable as the name is used vy something else?
Run with /v:diag and you'll get dumps of all the inputs and/or variables as they change.
Or if on V4, use the MSBuild Debugger
And buy the Hashimi et al MSBuild book