Yes, Jochen, you're right, I came up with the possibility you mentioned as well. It's not a good idea. Thanks.

And thank you very much for your solution, Jason, that's brilliant.

2017-04-13 23:47 GMT+08:00 Jochen Theodorou <blackdrag@gmx.org>:


On 13.04.2017 16:22, bo zhang wrote:
Thanks for your reply.

Actually, I'm writing a Gradle plugin in which I want to apply Gradle's
up-to-date check
<https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks>
and treated some closures as task input. That is to say, if a
user-defined closure in build.gradle doesn't change between two builds,
I can consider the task as "up-to-date" and skip them.

For example, a user writes a configuration block in build.gradle:

...
someConfiguration {
     "That is my closure"
}
...

As long as that closure doesn't change, the task depending on it should
be considered as "up-to-date".

yes... I am wondering if the assumption is ok though...

someConfiguration {
  compile.transitive = project.hasProperty("transitiveCompile")
}

Even if the Closure itself has always the same class, it may at any point produce different effects. Your assumption works only based on no side effects.

bye Jochen