[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:
Duplicate
Duplicated by GRADLE-1910 Task should be considered out-of-date... Resolved

 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:
build.gradle:

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.

Generated at Wed Jun 30 12:35:25 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.