I have a spring boot 1.5.1 project that uses profile properties file. In my /src/main/resources I have all my properties files
When using IntelliJ 2016.3.4 I set the
Run Configuration | Active Profile
to "local" and run it. I see this in the console:
The following profiles are active: local
But there is a value in the property file
data.count.users=2
and used as:
#Value("${data.count.users}")
private int userCount;
that is not being picked up and thus causing the error:
Caused by: java.lang.IllegalArgumentException: Could not resolve
placeholder 'data.count.users' in string value "${data.count.users}"
However, if I run this via gradle
bootRun {
systemProperty 'spring.profiles.active', System.properties['spring.profiles.active'] }
as
gradle bootRun -Dspring.profiles.active=local
then everything starts up using the local profile as expected. Can anyone see why this is not being properly picked up? In IntelliJ Project Structure I have my /src/main/resources defined as my Resource Folders.
UPDATE:
Adding screenshot of Configuration:
I could be wrong here but it doesn't look like the spring.profiles.active environment variable is actually set in your configuration, regardless of what you've selected as your Active Profile. This may be a bug with IntelliJ.
However, setting the environment variable in Run -> Edit Configurations definitely works for me.
Pease add Spring facet to your Spring Boot module to get full support
Is classpath of module heimdall the correct one, i.e. does it contain the shown resources folder with your application.properties?
If this doesn't help, please file a minimum sample project reproducing the exact structure of your project in our bugtracker, there are too many variables to investigate https://youtrack.jetbrains.com/issues/IDEA.
Using -Dspring.config.location in VM options in IntelliJ helped me.
-Dspring.config.location=file:/C:/Users/<project path>/src/main/resources/application-dev.properties
This could also be due to a non-standard configuration setup, for instance:
src/main/resources
├── application.properties
├── config1
│ ├── application-dev.properties
│ ├── application-prod.properties
│ ├── application.properties
│ └── logback-spring.xml
├── config2
│ ├── application-dev.properties
│ ├── application-prod.properties
│ ├── application.properties
│ └── logback-spring.xml
└── config3
├── application-dev.properties
├── application-prod.properties
├── application.properties
└── logback-spring.xml
This can be solved by passing using the parameters logging.config & spring.config.name for logback & spring respectively. For the above example:
java -jar \
-Dspring.profiles.active=dev \
-Dlogging.config=classpath:config1/logback-spring.xml \
-Dspring.config.name=application,config1/application \
target/my-application.0.0.1.jar
Here root application.properties is used, overridden by config1/application.properties, overridden by config1/application-dev.properties. The parameters (environment variables) can be specified in IDEA's run configuration in VM Options.
As far as advanced IDE support (highlighting, completion etc.) is concerned, there is an open issue for complex/custom configuration setups: IDEA-180498
Related
I'm new to Kotlin so forgive me if this is an easy question. I'm writing a kotlin script that I hope will utilize a custom Hashtable implementation to store data from a file. I'm having trouble getting the script to find the HashTable class.
Here is my structure:
.
├── scripts
│ ├── kotlin
│ │ ├── [other scripts]
│ │ └── wordcount.kts
│ └── tests
│ └── wc
│ └── smallfile.txt
└── src
├── main
│ └── kotlin
│ └── dataStructures
│ └── HashTable.kt
└── test
The script is wordcount.kts and the class I'm trying to import is in HashTable.kt. I tried import dataStructures.HashTable and import kotlin.dataStructures.HashTable to no avail. I also tried adjusting the PWD (in IntelliJ runtime configuration) to the project directory, also with no luck. How do I import HashTable correctly? Let me know if I can provide any further information!
import is used to link to things that are on your classpath, so before you can use that you need to allow the compiler to actually find that HashTable class.
You have a couple of options, I would however recommend to rename wordcount.kts to wordcount.main.kts (kotlin script requires the executable to be named x.main.kts for most features to work), HashTable.kt to HashTable.kts and link it with #file:Import(<path-to-hashtable.kts>).
If you can't rename the hashtable you will need to import it either by compiling it to a class file and adding it to the classpath with kotlinc -script -cp <dir-with-.class> wordcount.main.kts. Or compile to a jar and link the jar with #file:DependsOn<path-to-jar> in the script.
For the reference to all this stuff, look here: https://github.com/Kotlin/KEEP/blob/master/proposals/scripting-support.md
Quick question - since when Cucumber doesn't need any separate runner class with steps glued etc? Nothing else is needed currently after adding JUnit dependency to pom.xml? I've just setup a simple project and as I can see nothing besides chromedriver, step definitions, feature files and Selenium/JUnit/Cucumber dependencies is needed. Was it always like that? Because I remember these projects were uneasy to setup because of that class and few other things. Was I just stupid back then, or did something change and it's easy now?
Quite a few things have improved! Just not the thing you mentioned.
When you are using the CLI (either directly or through IDEA) Cucumber will search the entire class path for step definitions and feature files. This means that things usually just work.
To integrate with JUnit4 you will still need a runner class. However unless you tell it otherwise with #CucumberOptions the runner class will look for features and glue in the package and subpackages it is in.
So if you put everything in the right group and in the same package no additional configuration is needed. You should make use of this!
There is a little gotcha when using maven. If you put your feature files in the src/test/java folder, maven won't copy them to your class path. Features should always go into src/test/resources.
~/Projects/cucumber/cucumber-jvm/examples/calculator-java-junit4$ tree
.
├── pom.xml
└── src
├── main
│ └── java
│ └── io
│ └── cucumber
│ └── examples
│ └── calculator
│ └── RpnCalculator.java
└── test
├── java
│ └── io
│ └── cucumber
│ └── examples
│ └── calculator
│ ├── RpnCalculatorSteps.java
│ └── RunCucumberTest.java
└── resources
├── cucumber.properties
└── io
└── cucumber
└── examples
└── calculator
└── basic_arithmetic.feature
You can also do the 10 minute tutorial to get a fresh start: https://cucumber.io/docs/guides/10-minute-tutorial/
I am trying to port my old CMake to modern CMake (CMake 3.0.2 or above). In the old design I had multiple CMakelists.txt, each directory contained a CMakeLists.txt file.
My current project's directory structure looks like :
.
├── VizSim.cpp
├── algo
├── contacts
│ ├── BoundingVolumeHierarchies
│ │ └── AABBTree.h
│ └── SpatialPartitoning
├── geom
│ └── Geometry.h
├── math
│ ├── Tolerance.h
│ ├── Vector3.cpp
│ └── Vector3.h
├── mesh
│ ├── Edge.h
│ ├── Face.h
│ ├── Mesh.cpp
│ ├── Mesh.h
│ └── Node.h
├── util
| |__ Defines.h
| |__ Math.h
|
└── viz
└── Renderer.h
What I was planning to do was just use a single CMakelists.txt and place all the cpp files in SOURCE and all the headers in HEADER and use add_executable.
set (SOURCE
${SOURCE}
${CMAKE_CURRENT_SOURCE_DIR}/src/mesh/Mesh.cpp
${CMAKE_CURRENT_SOURCE_DIR}/src/math/Vector3.cpp
${CMAKE_CURRENT_SOURCE_DIR}/src/VizSim.cpp
....
)
set (HEADER
${HEADER}
${CMAKE_CURRENT_SOURCE_DIR}/src/mesh/Mesh.h
${CMAKE_CURRENT_SOURCE_DIR}/src/math/Vector3.h
....
)
add_library(${PROJECT_NAME} SHARED ${SOURCE})
Doing this I am worried if using a single CMakeLists.txt is good practice. So does single CMakeLists.txt suffice or do I need a CMakeLists.txt for each folder?
I can only think of one good reason to have multiple CMakeLists.txt in my project and that is modularity.
Considering my project will grow eventually.
This is a bit long for a comment – so I make it an answer:
In one of my projects (a library), I have that many sources that I started to move some of them in a sub-directory util.
For this, I made separate variables:
file(GLOB headers *.h)
file(GLOB sources *.cc)
file(GLOB utilHeaders
RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/util/*.h)
file(GLOB utilSources
RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/util/*.cc)
To make it nice looking / more convenient in VisualStudio, I inserted source_groups which generates appropriate sub-folders in the VS project. I believe they are called "Filters".
source_group("Header Files\\Utilities" FILES ${utilHeaders})
source_group("Source Files\\Utilities" FILES ${utilSources})
Of course, I have to consider the variables utilHeaders and utilSources as well where the sources have to be provided:
add_library(libName
${sources} ${headers}
${utilSources} ${utilHeaders})
That's it.
Fred reminded in his comment that I shouldn't forget to mention that file(GLOB has a certain weakness (although I find it very valuable in our daily work). This is even mentioned in the CMake doc.:
Note: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.
So, using file(GLOB, you shouldn't never forget to re-run CMake once files have been added, moved, or removed. An alternative could be as well, to add, move, remove the files directly in the generated built-scripts (e.g. VS project files) and rely on the fact that the next re-run of CMake will those files cover as well. Last but not least, a git pull is something else that it's worth to consider a re-run of CMake.
I would always recommend a CMakeList.txt file per directory. My reasons:
locality: keep everything in the same folder that belongs together. This includes the relevant parts of the build system. I would hate it to navigate to the root folder to see how a library or target was invoked.
separation of build artifacts and related build code: Tests belong below test, libraries below lib, binaries below bin, documentation below doc, and utilities below utils. This may vary from project to project. When I have to make a change to the documentation, why should I wade through dozens of unrelated CMake code? Just have a look into the right CMakeLists.txt.
avoid handling of paths: In most cases relative or absolute paths including stuff like ${CMAKE_CURRENT_SOURCE_DIR} can be avoided. That leads to maintainable build code and reduces errors from wrong paths. Especially with out-of-source build, which should be used anyway.
localization of errors: If a CMake error occurs it is easier to locate the problem. Often a sub-directory can be excluded as a first workaround.
I have multiple environments (dev/qa/prod) for my application. I would therefore like to differentiate the log conversion pattern based on environment. I have an env variable set which stores which environment the application is running it. But, how do I get log4j.properties to read this env variable?
This is my what my current properties file looks like:
log4j.rootLogger = INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern= [%d{yyyy-MM-dd HH:mm:ss}] my-api.%-5p: %m%n
I have tried following the log4j lookup docs, but this still does not include the environment in my log file.
log4j.appender.stdout.layout.ConversionPattern= [%d{yyyy-MM-dd
HH:mm:ss}] ${env:ENVIRONMENT}-my-api.%-5p: %m%n
The output looks like this:
[2018-01-22 14:17:20] -my-api.INFO : some-message.
But I want it to look like this:
[2018-01-22 14:17:20] dev-my-api.INFO : some-message.
You may also try a pattern that has become some sort of standard in Luminus and other frameworks. You create an env directory that holds prod/dev/test subfolders with some additional code and resources. In your lein project, for each profile you specify where to find those files in addition to the default path.
As the result, you've got three different log settings. Each of them will be loaded depending on what are you doing. When just develop the code -- from env/dev/resources/log4j.properties and when running tests -- from env/test/resources/log4j.properties.
Here is an example:
$ tree env
.
├── dev
│ └── resources
│ └── log4j.properties
├── prod
│ └── resources
│ └── log4j.properties
└── test
└── resources
└── log4j.properties
Some bits from the project.clj:
:profiles {:dev {:plugins [[autodoc/lein-autodoc "1.1.1"]]
:dependencies [[org.clojure/clojure "1.8.0"]
[log4j/log4j "1.2.17"]]
:resource-paths ["env/dev/resources"]}}
For test profile, you probably may want to specify both dev and test paths.
I have a shared Windows8.1 project with a Phone and Desktop project in it. I defined different configurations to build x86/x64 for desktop and ARM for phone.
msbuild works fine without error, but there is no final *.appxbundle file on the output folder (or anywhere else) although i set the parameter AppxBundle=Always.
my command looks like this:
msbuild myApp.sln /p:OutputPath=%OUTPATH%;Configuration=Phone;Platform=ARM;AppxBundle=Always;AppxBundlePlatforms=ARM
/t:Rebuild,Publish
The output is:
OUTPATH
├── ForBundle
│ └── AppxManifest.xml
├── AppxManifest.xml
├── App.WindowsPhone.build.appxrecipe
├── App.WindowsPhone_3.2.1_ARM.appx
├── App.WindowsPhone_3.2.1_scale-100.appx
├── App.WindowsPhone_3.2.1_scale-140.appx
├── App.WindowsPhone_3.2.1_scale-180.appx
├── resources.pri
└── SomeDependency.winmd
I tried to pack this folder with makeappx.exe bundle but this didn't work and I realized the folder looks a bit different to what is into a appxbundle.
Creating a appxbundle via VS GUI is no problem, but I would like to automate that step!
Thanks in advance!
There's a hint comment in Microsoft.AppXPackage.Targets:
When building on the command line or in TFS (determined by looking at the $(BuildingInsideVisualStudio) property), if build is
invoked on an
app package-producing project, the package for the project will be produced as part of building the project without specifying
any additional
flags or targets. This is control by an MSBuild property named GenerateAppxPackageOnBuild which is set to true by default.
If $(BuildingInsideVisualStudio) = false and $(GenerateAppxPackageOnBuild) = true, then build will also produce a
package.
true
FYI, the file has moved for VS 2022, new location isL
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage