[GRADLE-2096] jar Task of the Java Plugin has incorrect up-to-date check Created: 10/Feb/12 Updated: 04/Jan/13 Resolved: 02/Mar/12 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-7 |
Fix Version/s: | 1.0-rc-1 |
Type: | Bug | ||
Reporter: | Stefan Sieber | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Attachments: | jarBugTest-v2.zip | ||||||||
Issue Links: |
|
Description |
When changing filtered Resources, the Jar task's up-to-date check doesn't always work. When the version variable changes in the example below, processResources is executed correctly (content of the file in build/resources changes), but the jar - task says it's up-to-date: $ gradle jar The up-to-date doesn't always fail, but after trying it a few times, it should build.gradle: — I attached the zipped sample project. |
Comments |
Comment by Peter Niederwieser [ 11/Feb/12 ] |
Works fine for me; I never see the Jar task up-to-date after changing the version. Can you attach the output of gradle -v and gradle -i jar? |
Comment by Stefan Sieber [ 13/Feb/12 ] |
Sorry I just noticed that the first example works, because the version number is in the file name. I tried it by switching the version number back and forth. The check failed whenever I used a version number that already existed. I changed the example (jarBugTest-v2.zip) to use another attribute than the version number (bar): apply plugin: 'java' version = '2.0.5' bar = '5' processResources { inputs.property('test-attribute', bar) filter (org.apache.tools.ant.filters.ReplaceTokens, tokens: ['bar': bar]) }The first time the build runs, the jar is generated correctly (with foo.properties having the filter applied). After changing the value of bar, the jar task says that the jar is up to date. Here are my log outputs: C:\Temp\jarBugTest>gradle -v ------------------------------------------------------------ Gradle build time: Donnerstag, 5. Januar 2012 10:24 Uhr UTC C:\Temp\jarBugTest>gradle jar -i BUILD SUCCESSFUL Total time: 5.46 secs HTH |
Comment by René Gröschke (Inactive) [ 23/Feb/12 ] |
I've digged a bit into this problem. It seems that our state caching for files has problems when the lastModified attribute and the size of the file itself hasn't changed. Though I would have expected to see a different timestamp for the modified file. |