@danny re: upToDate etc .. each case ends up eventually with some kind of explanation (it is 'just software') -- but each time its different, when it doesnt work how I expect it will it can take hours or days to debug or give up on. Its not only upToDate, problems arise with transitive task dependencies, cached statuses, entirely skipped tasks or tasks reran unexpectedly ... For File based tasks, its tricky enough to uncover the implicit 'conventions' -- but they do seem to be much more consistent behaviour. I believe this is inherent in much of the lifecycle rules -- the history of build systems is very much about pushing files around its difficult (and not necessarily better) to be fully agnostic about what dependency really means in the domain. But it does make it harder to do non-files based dependencies. Example: there is no mechanism I am aware of that can be cleanly used to provide the equivalent of a file timestamp and content/checksum for non-file 'resources' -- as a 'resource' they are not modeled at all, so one has to go to the task abstraction to work around holes in the metadata. I have had some luck by persisting a 'status' file for each non-file type resource dependency, toudhing it (and changing its contents) needed -- but there is no hooks I know of to know when the checks need to be rerun or when gradle is looking at them. Very deeply hidden (intentionally). So I was wondering, if in Kotlin DSL maybe there is a better way to manage non-file dependencies. SUch as creating a derived Dependency object that behaves 'like a file' ? Just speculating.