How to pass system property to Gradle task

问题:

I'm using Gradle spring-boot plugin and I need to select a spring active profile for the test run.

How do I pass spring.profiles.active system property to the bootRun plugin's task?

What has already failed:

task bootRunLocal {
    systemProperty "spring.profiles.active", "local"
    System.setProperty("spring.profiles.active", "local")
    tasks.bootRun.execute() // I suspect that this task is executed in a separate JVM
}

and some command line magic also fails:

./gradle -Dspring.profiles.active=local bootRun

Could someone kindly help me solve my troubles?

Update from the answers and comments:

I'm able to set the systemProperty and pass it to the spring container by doing :

run {
    systemProperty "spring.profiles.active", "local"
}

However, when I do this, the local profile is being set for both bootRun task and bootRunLocal task. I need a way to set this property for bootRunLocal task and call booRun task from bootRunLocal.

That might sound very simple, but I come with peace from the structured world of Maven.

回答1:

task local {
    run { systemProperty "spring.profiles.active", "local" }
}

bootRun.mustRunAfter local

Then run gradle command as:

gradle bootRun local

回答2:

I know I'm late here... but I recently faced this exact issue. I was trying to launch bootRun with spring.profiles.active and spring.config.location set as system properties on the command line.

So, to get your command line "magic" to work, simply add this to your build.gradle

bootRun {
    systemProperties System.properties
}

Then running from the command line...

gradle -Dspring.profiles.active=local bootRun

Will set local as the active profile, without needing to define a separate task simply to add the env variable.

回答3:

There is no generic way to pass system properties to a task. In a nutshell, it's only supported for tasks that fork a separate JVM.

The bootRunLocal task (as defined above) will not execute in a separate JVM, and calling execute() on a task isn't supported (and would have to happen in the execution phase in any case). Tests, on the other hand, are always executed in a separate JVM (if executed by a Test task). To set system properties for test execution, you need to configure the corresponding Test task(s). For example:

test {
    systemProperty "spring.profiles.active", "local"
}

For more information, see Test in the Gradle Build Language Reference.

回答4:

For gradle 2.14 below example works. I have added as below.
When System.properties['spring.profiles.active'] is null then default profile is set.

  bootRun {
       systemProperty 'spring.profiles.active', System.properties['spring.profiles.active']
    }

command line example

gradle bootRun -Dspring.profiles.active=dev

回答5:

Just for reference if anyone will have this issue:

Vlad answer didn't quite worked for me but this one works great with 2.4,

task local <<{
    bootRun { systemProperty "spring.profiles.active", "local" }
}
local.finalizedBy bootRun

then gradle local

回答6:

SPRING_PROFILES_ACTIVE=local gradle clean bootRun

This is according to this and this and it works.

回答7:

Responding to OP's exact request here ...

How do I pass spring.profiles.active system property to the bootRun plugin's task?

And assuming by "pass" the OP meant "pass from commandline" or "pass from IDE invocation" ... This is how I like to do it.

Add this to build.gradle:

/**
 * Task from spring-boot-gradle-plugin, configured for easier development
 */
bootRun {
    /* Lets you pick Spring Boot profile by system properties, e.g. gradle bootRun -Dspring.profiles.active=dev */
    systemProperties = System.properties
}

Then when you invoke it, use the familiar Java flag for setting a system property

gradle bootRun -Dspring.profiles.active=local

There is one main advantage of sticking to system properties, over the environment variables option (SPRING_PROFILES_ACTIVE=local gradle bootRun) ... and that's easy portability between Linux/OS X (bash, etc.) and Windows (cmd.exe anyway).

I learned this way from this blog post.

(UPDATE: Ah somehow I had missed @Erich's response with same recommendation. Oops! I'm leaving my answer, because of the additional details about portability, etc.)

回答8:

You can create a new task (in discussed case with name bootRunLocal), that would extend org.springframework.boot.gradle.run.BootRunTask and setup properties before task execution. You can create such a task with following code:

task bootRunLocal(type: org.springframework.boot.gradle.run.BootRunTask) {
    doFirst() {
        main = project.mainClassName
        classpath = sourceSets.main.runtimeClasspath
        systemProperty "spring.profiles.active", "local"
    }
}

More details can be found here: https://karolkalinski.github.io/gradle-task-that-runs-spring-boot-aplication-with-profile-activated/

回答9:

This works:

SPRING_PROFILES_ACTIVE=production ./gradlew app-service:bootRun

回答10:

Starting from SpringBoot 2.0.0-M5 setSystemProperties() is no longer a method of the task bootRun. The build.gradle needs to be updated to

bootRun {
    execSpec {
        // System.properties["spring.profiles.active"]
       systemProperties System.properties
    }
}

This is as springBoot's run task uses org.gradle.process.JavaExecSpec

This works for me using Gradle 4.2

回答11:

According to the spring-boot-gradle-plugin documentation you should be able to pass arguments like this

./gradlew bootRun --args='--spring.profiles.active=dev'

Seems like this is a new gradle feature since 4.9. I used it in my project and it worked out of the box.

回答12:

with run command you can add to build file run { systemProperties = System.properties } and start with gradle run -Dspring.profiles.active=local

回答13:

Another way which doesn't require any support from the gradle task: Set the JAVA_TOOL_OPTIONS environment variable:

JAVA_TOOL_OPTIONS='-Dfoo=bar' gradle ...

Or if the variable might already contain anything useful:

JAVA_TOOL_OPTIONS="$JAVA_TOOL_OPTIONS -Dfoo=bar" gradle ...

回答14:

// defualt value
def profiles = 'dev'

bootRun {
    args = ["--spring.profiles.active=" + profiles]
}

Then you can simply pick a specific version when starting a gradle task, like

./gradlew bootRun -P dev

"dev" is gonna to take place "prod"