No Such Property Exception using Gradle expand(ProcessResource)

Hello All,

I’m a beginner learning Gradle. I have an application.yaml file containing all the properties required for the project. I have written a processResource with expand to access the build info properties in the application.yaml file on the build so that I can use the /info actuator provided by Spring Boot. The problem I am facing is my application.yaml file contains another placeholder defined within the file. Now when I try to build the project I get No such property: xss for class: SimpleTemplateScript.

Sample application.yaml File

value: zzzz

version: project.version

build.gradle File


The expand is attempting to replace the properties in the application.yaml file with their values, and when it sees {} it is trying to replace it with the value of that property, but the property is not set , so I am getting the error. Is there any workaround which excludes the {} from the expand.


Your value must be ${}, not just {} as the $ is the key to resolving a property reference or executing groovy in the template. To keep the value as is, you’ll need to escape the $ in the yaml file with a \. The line should read: url:\${}/set

Thank you james. Its ${} as you said. I have tried using a \ escape. The build is successful and the application.yaml file seems to be getting the values properly. But when i run the project, i am getting an exit code 1 error. If i remove the \ from the the url and comment out the line everything is working as exepected.
Is there any other way of doing apart from using \ in the url.


The \ should not be present in the file that is actually used by the application. In addition to adding the actual values, the processResources task should also be removing the \ as part of the processing. How are you running the application?

There are also a couple more items in your original post that should cause an error, so I’m concerned there might be seemingly small details not mentioned that are impacting you. Escaping the $ is the correct way to not try to process a value that should remain as a literal, so the focus should really be on what is the difference of the YAML file that ends up in the built JAR (not the one in the original source) when it works vs. when it does not work?