[GRADLE-2936] Gradle considers tasks up-to-date even if implementation of the task's type has changed Created: 27/Oct/13 Updated: 25/Jan/17 Resolved: 03/Jun/16 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | None |
Fix Version/s: | 3.0-milestone-1, 3.0-rc-2 |
Type: | Bug | ||
Reporter: | Gradle Forums | Assignee: | Lóránt Pintér |
Resolution: | Fixed | Votes: | 4 |
Issue Links: |
|
Description |
It seems that Gradle considers tasks up-to-date even if the implementation of the task's type in buildSrc changed after the last task execution. The following small example that illustrates this behavior: import test.HelloWorldTask task test(type: HelloWorldTask) { greetingFile = file('someFile') output = file('someDir') } HelloWorldTask.groovy in buildSrc (omitting imports and package declaration): public class HelloWorldTask extends DefaultTask { @InputFile File greetingFile; @OutputDirectory File output; @TaskAction public void greet() { println "hello ${greetingFile.name}" } } After executing task 'test' once, it is considererd up-to-date in following Gradle executions even if HelloWorldTask.groovy is changed. Is this behavior intended? My goal is that after every change of my task implementations, at least the corresponding tasks are no longer considered up-to-date. (The person executing the build might not know that buildSrc changed, and, hence, will probably not force Gradle to consider the task out-of-date.) Is it possible to achieve this goal, e.g., by specifying the buildSrc as a task input, such that the task will not be skipped after changing the implementation of the task's type in buildSrc? |
Comments |
Comment by Gradle Forums [ 27/Oct/13 ] |
It's a known limitation, and there isn't currently an easy way to overcome it. |
Comment by Serge [ 03/Apr/14 ] |
Isn't there any way to keep md5 of the *.gradle files and invalidate the the cache? This issue is very important, it makes gradle completely unreliable. This way gradle builds something based on some config used before but probably changed. |
Comment by Serge [ 26/Jul/15 ] |
Any update on this? |
Comment by Luke Daley [ 04/Aug/15 ] |
Not at this time. The bug still exists. |
Comment by Lóránt Pintér [ 03/Jun/16 ] |
Gradle now observes the full classpath of a task's implementation. |