[GRADLE-1110] UP-TO-DATE check works on 2nd and subsequent invocations in some cases Created: 11/Aug/10  Updated: 08/Feb/17  Resolved: 08/Feb/17

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

Type: Bug
Reporter: Spencer Allain Assignee: Unassigned
Resolution: Won't Fix Votes: 26

Attachments: File uptodate.tar    

 Description   

Running the attached trivial example highlights the issue.

When outputs.files is an empty set of files/dirs (the "clean" state of the system), the UP-TO-DATE check correctly identifies that it needs to run cachesFunny for depTask.

The second time depTask is invoked though, cachesFunny still runs again, even though all of the output dir(s)/file(s) have a timestamp newer than all of the input dir(s)/file(s).

The third and subsequent times, cachesFunny correctly is identified as UP-TO-DATE.

I'm not sure how the caching is working under the covers, but it appears that if there are not initial target files/dirs, that nothing is cached about that state (meaning no timestamp is retained). Once files/dirs do exist, the cache properly retains some timestamp for comparison. Since there doesn't appear to be any timestamp for the initial case, it blindly re-runs cachesFunny because it still thinks it never ran in the first place.

 Comments   
Comment by Adam Murdoch [ 01/May/13 ]

This is working as designed (though arguably that design is confusing initially). The `outputs.files` method is used to declare a set of files that will be produced rather than the set of files that were produced. As such, the arguments to `output.files` are evaluated before the task executes.

For your attached example, you need to use `output.dir generatedJava` and Gradle will figure out the rest for you.

We do plan to add some mechanism for a task to declare what it actually did do, to make this more efficient.

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 Benjamin Muschko [ 08/Feb/17 ]

As explained works as expected. Closing the issue. Please open an issue on GitHub in case you want to follow up.

Generated at Wed Jun 30 11:47:09 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.