[GRADLE-1298] Change in filtered resource not picked up by archive tasks Created: 09/Jan/11 Updated: 26/Jan/17 Resolved: 26/Jan/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 0.9.1 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Joern Huxhorn | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 4 |
Attachments: | bugtest.zip | ||||||||||||||||
Issue Links: |
|
Description |
The attached example contains a resource app.properties with a timestamp containing the time of the build. Due to
processResources { outputs.upToDateWhen { false } }
as suggested by Adam. This does not prevent that jar (and other archive tasks) aren't reexecuted even though the resource did change. To reproduce, just build the example using gradle and start the app with java -jar build/libs/bug-0.0.1-SNAPSHOT-all.jar The timestamp won't change upon rebuild. The only way to get an updated timestamp is calling gradle clean build |
Comments |
Comment by Joern Huxhorn [ 10/Dec/12 ] |
Updated and simplified example showing the problem. Execute 'gradle' multiple times. This will execute the BugExample application. It should print a different timestamp for each run but is always printing the same one. Execute 'gradle clean' to force a fresh timestamp on next build. |
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:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Joern Huxhorn [ 15/Nov/16 ] |
It looks like this isn't an issue anymore. Can't reproduce it anymore with Gradle 3.2. |
Comment by Benjamin Muschko [ 26/Jan/17 ] |
Closing as the issue is not reproducible anymore as reported. |