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

This is extract from our root build.gradle file:

// Apply the baseline configuration properties
applyProperties("base.gradle")

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

// Apply local overrides
applyProperties("local.gradle")

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'
}

Thanks for the information.

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

`

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!

I still advocate my JIRA issue.

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.