Spring-boot: project.version not accessible in application.properties with gradle build

Created on 10 Sep 2014  路  15Comments  路  Source: spring-projects/spring-boot

In the docs here there is mention of using syntax like this this in application.properties to access a version number via actuator:

info.build.version=${project.version}

When using gradle, the project.version does not seem to be populated though, resulting in actuator just printing the "${project.version}" characters, not resolving the code to the version.

For the sake of testing that these variables can be resolved, I also tested this and it worked fine:

info.build.random=${random.long}

The docs state that this is a Spring Boot Maven feature, but I was hoping it would work for Gradle too. Is this expected to work for Gradle or is there an alternative perhaps?

If it's of any help, here it my build.gradle file contents:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath('org.springframework.boot:spring-boot-gradle-plugin:1.1.5.RELEASE')
    }
}

repositories {
    mavenCentral()
}

apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'spring-boot'


dependencies {
    // tag::jetty[]
    compile('org.springframework.boot:spring-boot-starter-web') {
        exclude module: 'spring-boot-starter-tomcat'
    }
    compile('org.springframework.boot:spring-boot-starter-jetty')
    // end::jetty[]
    // tag::actuator[]
    compile('org.springframework.boot:spring-boot-starter-actuator')
    // end::actuator[]
}

version = '1.0.0'
documentation

Most helpful comment

@pnowy
an example showing the values used in each of the following files would be really helpful please,

  • build.gradle
  • application.properties (if required)
  • Java main class showing how to reference the buildInfo values
    also where I can find a list of all the buildInfo values available

All 15 comments

Gradle has an equivalent. You need to add property expansion to the Java plugin's existing processResources task:

processResources {
    expand(project.properties)
}

You can then reference any of the project's properties in your resources and they'll be expanded. For example:

info.build.version=${version}

See section 16.6.2 of Gradle's documentation for some more information.

Thanks for looking at this @wilkinsona but unfortunately it still doesn't work. I've pushed a sample project with this here: https://github.com/ctl80/actuator-test. It contains the processResources change. The test I'm using it to start it up with "gradle clean bootRun" and then hit it with curl localhost:8080/info which as of now returns back {"build":{"version":"${version}"}}

That's by design. bootRun is intended for use at development time. As described in the documentation src/main/resources is used, rather than resources that have been "built", so that resources are reloadable. If you build your application and run its jar file, you should see that the resource has been processed and the properties expanded.

I built and ran as a jar and it works well. Thanks @wilkinsona !

Reopening to remind me to add the Gradle snippet to the docs

This seems to have helped to make that version available, but as a result I've run into a problem with other resources. It seems processResources will also try to process other things in resources (seems reasonable) and dies trying to process things that aren't nice property files. I've updated the sample repo by added a keystore to show how it fails.

I can exclude other property files from processing, but then they are not included in the war. @wilkinsona , Is there a recommended way to get the expand behavior without impacting the other resources in the project? I've seen references to the copy task or sourceSets, but I get the feeling I'm missing a better option here.

Take a look at the javadoc for the copy task (which is what processResources is). There are several methods for working with a subset of the resources. For example, you can do this:

processResources {
    filesMatching('**/*.properties') { expand(project.properties) }
}

Thanks, I was trying include and exclude, but missed the filesMatching.

I followed the same steps to get the version number in my spring boot app with gradle.
1) Added the below lines in my gradle build file.
version = 'xxxxxxxxx'
processResources {
expand(project.properties)
}
2) Trying to get the version in application yaml file as,
info:
app:
version: ${version}

When trying to run the gradlew bootRun task to start the app I am getting the following error.

gradlew bootRun
Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
:compileJava
:processResources FAILED

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ':processResources'.

Could not copy file '/home/dcpdev/projects/test/src/main/resources/static/app/app.js' to '/home/dcpdev/projects/test/build/resources/main/static/app/app.js'.

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 4.69

Can some one help me on resolving this issue.

Thanks,
Anil.

@nabinnepal Stackoverflow is a better place for this sort of question

Please put a crosslink to your StackOverflow question here, if you post one. Thx!

For my reference: if the ${...} parentheses are causing _"Could not resolve placeholder"_ errors, you can alternatively use <%=...%>. N.B. tested with a *.properties file, not sure how this would work for an XML file.

It's closed but maybe it will be useful for someone. Everything what I need to to (Gradle 3.1, SpringBoot 1.4.1) was:

springBoot  {
    buildInfo()
}

It works both for Intellij IDEA and run by JAR file.

@pnowy
an example showing the values used in each of the following files would be really helpful please,

  • build.gradle
  • application.properties (if required)
  • Java main class showing how to reference the buildInfo values
    also where I can find a list of all the buildInfo values available

@kopax AFAIK, Gradle doesn鈥檛 care about the file鈥檚 format as long as it鈥檚 text (rather than binary). If you need some further guidance, please ask on Stack Overflow.

Was this page helpful?
0 / 5 - 0 ratings