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.
Related
As an example, when using the "extract variable" feature, the variable is declared "var" rather than "final", although the latter is what I usually end up assigning.
The "analysis_options.yaml" file seems to know a linter flag "prefer_final_locals" (and prefer_final_fields).
Is there a way to make the IDE make use of these?
The analysis_options.yaml located in the flutter installation directory is NOT used by IDEA as default. In order for these configurations to be applied, the file has to be copied to the root of a dart/flutter project (so, next to the pubspec.yaml). The mentioned flags regarding finals and much more then get applied without any further action required.
Setup:
I created a new SBT project in IntelliJ IDEA 13.0.2 Ultimate (Fig. 1).
I named the project "test" (Fig. 1).
After creation, Fig. 2 shows the project directory structure.
I have three main questions:
Question 1:
None of the source folders (shown in Fig. 5) were generated by IDEA 13.
Should I create src/main/scala (and others) by hand ?
Question 2:
What is the difference between the two modules created ("test"- Fig. 4 and "test-build" - Fig. 5) ?
Which one should I use ?
I assume test, but what is the purpose of test-build then?
Question 3:
What is the meaning of "target/scala-2.10/src_managed/main" source
folder in the "test" module (Fig. 4)?
What should I use that for ?
What kind of sources should go there ?
Thanks for reading.
None of the source folders (shown in Fig. 5) were generated by IDEA 13.
You don't need them for proper SBT work and hence SBT doesn't insist on them available (and perhaps that's the reason why IDEA doesn't create them by default).
Should I create src/main/scala (and others) by hand ?
Nope. You will eventually, but for now you don't need to bother. Scala sources can go to the main directory of the project and SBT will see them.
There's a caveat however - you'll have to use New > File to create Scala files as the main directory is not marked as Sources root.
What is the difference between the two modules created ("test"- Fig. 4 and "test-build" - Fig. 5) ?
test is your project while test-build is the build configuration's project. SBT is recursive.
Which one should I use ?
test
I assume test, but what is the purpose of test-build then?
See sbt is recursive and read the entire Getting Started.
What is the meaning of "target/scala-2.10/src_managed/main" source folder in the "test" module (Fig. 4)?
What should I use that for ?
What kind of sources should go there ?
It's SBT's output directory and you should not worry about it for now.
I strongly advise reading the entire Getting Started to get you going with SBT.
This is the first time that I'm giving a chance to IntelliJ, and to be honest it's not going quite well...
I have imported my Eclipse subprojects. They use external .jar dependencies and they are specified as with a variable, ie: $EXTERNAL_LIBS/derby.jar
When I have imported my projects, IntelliJ recognize the variable and ask me to give it a value, which I misspointed to a wrong path. Now I see on the subproject properties all the module dependencies pointing to a wrong path.
I go to File - Settings and change the value of my EXTERNAL_LIBS to the right path, but all the current dependencies doesn't seem to reflect the change. They still pointing to the first and wrong path.
Am I suppose to go one by one? I do not understand how IntelliJ manages Path Variables... When I try to add a new module dependency it forces me to choose it from the hard drive, and doesn't give the change to use any of these variables.... The documentation is quite poor as well....
Path variables can be changed in File | Settings | Path Variables.
They are handled transparently by the IDE on project load and on project save.
When project loads and contains path variables, IDE will substitute them with the actual paths defined in Settings. If no path variable is defined yet, IDE will ask you to define it.
When the project files are saved on disk, IDE will transparently and silently replace all the paths matching defined variables with the variable name.
It works fully automatically and user doesn't have to define variables explicitly in any IDE settings, just use the actual paths in your libraries, they will be replaced with the corresponding variables on project save so that your project files are portable and other users can define different values for the path variables when opening this project for the first time.
I'm working with gendarme for .net called by Sonar (launched by Jenkins).
I've a lot of AvoidVisibleFieldsRule violations. The main violations are found in the generated files. As I can't do anything on it, i would like to exclude *.designer.cs from the scan.
I can't find a way to do that. There is a properties in Sonar to exclude generated files but it doesn't seem to be applied for gendarme.
Is there a way to do such a thing ?
Thanks for all
Gendarme expects you provide an ignore list,
http://www.mono-project.com/Gendarme.FAQ
https://github.com/mono/mono-tools/blob/master/gendarme/self-test.ignore
The ignore file format is bit of weird, but you can learn it by experiments.
Indeed that is actually not normal at all. Generated code is excluded by the plugin with the standard configuration. What version of the C# plugins are you using ?
Anyway, the configuration property you can try is "sonar.exclusions" (see http://docs.codehaus.org/display/SONAR/Advanced+parameters).
If you do not solve your problem right away, the best thing would be to drop a mail to the user mailing list (see http://www.sonarsource.org/support/support/) and send the verbose output of your build. To get this output simply add "-X" to the command line.
Hope it helps
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