In IntelliJ, how do I pass command line variables when building with Maven (TestNG run configuration)? - maven

I'm trying to do the following, but in IntelliJ with a TestNG run configuration:
mvn clean install -Dfoo=bar
So, the value for the foo system property should be bar:
System.out.println(System.getProperty("foo"));
======
bar
All potential answers I've googled either tell me to hardcode variables into my pom.xml (which I can't do) or say to "just set it in Edit Configurations..." without showing what a properly set variable looks like. I dug through the IntelliJ manual too.
I tried all the logical names for "foo" in both Run/Debug Configurations/Parameters tab and Run/Debug Configurations/Environment Variables, such as Dfoo and -Dfoo.

Use a Maven configuration instead of a TestNG configuration. You can still run your TestNG tests from the Maven configuration:

Related

How can I run multiple profiles with Gradle + Spring boot? [duplicate]

This question already has answers here:
How to run bootRun with spring profile via gradle task
(15 answers)
Closed 3 years ago.
I am trying to learn using gradle with springboot from maven so I wanted to know how I can run my project in command line to pick up a different configuration file.
The scenario here is I have my properties eg.
application-qa.properties and application.properties
however If run gradle with something like ./gradlew -PspringProfile=qa bootRun
It loads only the default properties in application.properties and not the qa properties.
How do I accomplish that with gradle as with maven before?
This is what I have tried.
I created gradle run config in IntelliJ but this has not also worked,
Is there a commad-line option?
First of all, as another user said in the comments to your question, you are not using the correct name of the parameter.
But furthermore, you can't set the active profile with a project property through -P (at least not out of the box). You have a few other options.
A
Use --spring.profiles.active=qa as an argument like this:
gradlew bootRun --args='--spring.profiles.active=qa'
I don't think you can put that type of argument into the "arguments" list in the IntelliJ run configuration though, but you can put it directly into the "tasks" value instead if you like. But that's a bit weird.
B
Default to a particular environment in the Gradle build file when run though Gradle:
bootRun {
environment('spring.profiles.active', 'qa')
}
This makes sense if you are always running against the same environment when using the bootRun task from Gradle.
C
Set an environment variable spring.profiles.active=qa, either on your local computer or in the IntelliJ run configuration.

Profile Specific application.properties Not Applied During Unit Test

I'm writing integration tests, and I'd like to use Spring profiles to configure properties for each environment. However I'm finding profile specific application properties (e.g. application-dev.yml, application-prod.yml) in my src/test/resources directory aren't activated the same way they are in src/main/resources. It appears running tests with -Dspring.profiles.active=prod has no effect. Is it possible to activate a profile from the command line for tests?
Note: #ActiveProfiles isn't sufficient because I want to run the same tests against multiple environments.
I don't know if you have copied the file names from your workspace but 'applicaiton-prod.yml' has a typo in it. That could be the reason.
I found a similar issue reported in GitHub and the solution was applicable to my problem. The JVM system property spring.profiles.active wasn't getting picked-up in Gradle. So I modified my task as follows
integrationTest {
systemProperties = System.properties
}

how to set spring active profile environment variable in IntelliJ

I am using spring boot application (maven project) in eclipse. When I run test clean target of maven project, I want to load the active profiles
I have added the property spring.profiles.active=test,aop in application.properties and also in application-test.properties, this does not have any affect.
or setting this property in command line option of IntelliJ IDE as -Dspring.profiles.active=test,aop does not have an effect when the command is test clean. I have also tried setting the JVM argument of the Runner in Intelligent
however #ActiveProfiles("test") works when the test case class is executed from IntelliJ IDE( right click -> run TestCaseClass).
Any clues ?
Setting the VM Options with -Dspring.profiles.active=test
My Project is using MAVEN.
the easy was is
Right hand side click on MAVEN -> Expand the Profiles -> Click on desired profile.
Build and run
Please check the attached screenshot for more clarity

Is there a way to tell gradle which profiles should be used for the tests?

I use the yml configuration files pattern application-{default,dev,production}.yml.
To define which configuration application will use, I fix the environment SPRING_PROFILES_ACTIVE=dev so when the spring app run, it choose the correct configuration.
I have now theses two issues:
The ./gradlew build command also run the test command, test need to have the correct configuration as the application does when it start.
My jenkins does not have access to the database and the units tests keep failing.
Which make make ask:
Does the build command tries all the datasource in order ? Is there a way to specify the spring boot active profile ?
Is there another different approach for deploying spring-boots app in production from jenkins ?
Does anyone has a workaround except
./gradlew -x test build
This is not what I want.
Neither adding #ActiveProfile("dev") to my tests because this require source code modification.
Simply Create multiple property files.For Example:
application.properties
application-test.properties
application-production.properties
Provide different properties based on profile and
Below you can specify
which profile to load in you gradle.build file
def profile = "test"
bootRun {
args = ["--spring.profiles.active="+profile]
}
Put below code in the end of gradle file

Activate a profile based on environment

Here's my scenario:
Maven 2.0.9 is our build system
We install code to multiple environments
All of our environment-specific properties are contained in property files, one for each environment
We currently read these properties into maven using the properties-maven-plugin; this sub-bullet is not a requirement, just our current solution
Goal:
Perform certain parts of the build (ie. plugin executions) only for certain environments
Control which parts are run by setting values in the environment-specific property files
What I've tried so far:
Maven allows plugins executions to be put inside pom profiles, which can be activated by properties; unfortunately these must be system properties - ie. from settings.xml or the command-line, not from properties loaded by the properties-maven-plugin
If possible, we'd like to keep everything encapsulated within the build workspace, which looks something like this:
project
pom.xml
src
...
conf
dev.properties
test.properties
prod.properties
build-scripts
build.groovy <-- the script that wraps maven to do the build
install.groovy <-- ... wraps maven to do the install
Running a build looks like:
cd build-scripts
./build.groovy
./install.groovy -e prod
Is there any possible way to accomplish these goals with the version of maven we are using? If not, is it possible with a newer version of maven?
This isn't possible using just Maven. (See also How to activate profile by means of maven property?) The reason is that profiles are the first thing evaluated before anything else to determine the effective POM.
My suggestion is to write some preprocessor that parses your environment specific property files and converts them to the required system properties before launching Maven. This script can be included in your ~/.mavenrc so that it runs automatically before Maven is launched. Here is an example script that that assumes the properties file is in a fixed location:
properties=`cat /etc/build-env.properties`
while read line; do
MAVEN_OPTS="$MAVEN_OPTS -D$line"
done <<< "$properties"
If the properties file is not fixed, you'll just need to add something to the script to discover the location (assuming it is discoverable).

Resources