[GRADLE-2710] Properties are not reapplied from local file on Windows Seven. This behavior is not observed on Ubuntu. Created: 18/Mar/13  Updated: 03/Feb/17  Resolved: 03/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.4
Fix Version/s: None

Type: Bug
Reporter: Vadym Yepishov Assignee: Unassigned
Resolution: Won't Fix Votes: 0


When properties are applied from some local file (for example, 'local.gradle'), they are not updated with the next gradle build if they are changed in the mentioned above file.
For example, we have property named 'db.url', we made gradle build, and the property was applied in some source files. Then, this property is changed in the property file. gradle build is made again, but this property remains the same in the source files.
Workaround: remove '.gradle' subdirectory in the directory where gradle build is run.
Note: this bug is observed on Windows Seven, but not on Ubuntu.

Comment by Adam Murdoch [ 27/Mar/13 ]

Can you give more details about what you mean by 'the property was applied in some source files'?

Comment by Vadym Yepishov [ 28/Mar/13 ]

This is extract from our root build.gradle file:

// Apply the baseline configuration properties

// Determine the build environment (command-line: "-Penv=<environment>", default: local)
if (!hasProperty("env")) {
    println("Local build environment")
} else {
    println("Build Environment: " + env)

// Apply local overrides

void applyProperties(String filename) {
    File configFile = new File(filename)
    if (configFile.exists()) {
        println "Applying definitions from ${configFile.absolutePath}"
        apply from: configFile

Now, when I run gradle (using the gradle clean build command) for the first time (no .gradle folder in the directory I am running the tool), then the properties in the source files in the ${property} format are properly substituted with the values from the local.gradle file.
When I run gradle (using the same tasks) for the second time (.gradle folder is present after the first run), the values from the local.gradle file are not reapplied even if they were changed.
Please note that we have resource files with placeholders in the src/main/conf directory, and resource files with applied properties in the src/main/webapp folder, so placeholders in the files of the former directory are always in place.
If I remove the .gradle folder, then the changed values of the properties from the local.gradle file are reapplied again.
This behavior is observed on Windows Seven. On both Mac OS X and Ubuntu, you do not have to remove the .gradle folder to reapply changed values of properties.

The local.gradle file has the following format:

ext {
	some.property.first = 'some_property_first'
	some.property.second = 'some_property_second'
	// ...
	some.property.nth = 'some.property.nth'
Comment by Adam Murdoch [ 02/Apr/13 ]

Thanks for the information.

As a workaround, you can do something like `processResources.outputs.upToDateWhen

{ false }


Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Vadym Yepishov [ 17/Nov/16 ]

I still advocate my JIRA issue.

Comment by Benjamin Muschko [ 03/Feb/17 ]

I read the use case a couple of times but still have trouble with fully understanding it. I am not going to migrate the issue to GitHub for the following reasons:

  • A workaround was provided (not sure if works for you).
  • There are little votes for the issue.
  • I don't see us fixing the issue anytime soon given that it only happens on a specific OS and given other priorities.
  • I would have to see a working project that exposes the issue.

Please open an issue on GitHub if it is crucial to your workflow. Please also provide a reproducible example project as a GitHub repository.

Generated at Wed Jun 30 12:29:22 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.