Zip task still 'up-to-date' after 'into' directory changes

Old Forum Archive
1

The following task is always up to date when changing the ‘into’ directory. Is this the expected behavior or a bug? If its the former, then what is the correct workaround?

apply plugin:'java'
  task dist(type:Zip) {
   into 'dir1/'
   from jar
}
2

What do you mean by “when changing the ‘into’ directory”? This refers to a directory inside the generated zip.

3

I mean modify ‘dir1/’ to ‘dir2/’ and the run the build. Gradle does not see this change and the zip output is not updated.

4

I see. I believe it’s a known limitation that is yet to be addressed. I’m not aware of a generic workaround other than running ‘clean dist’ or ‘cleanDist dist’, or enforcing regeneration with ‘dist.outputs.upToDateWhen { false }’. Note that the dist zip will be regenerated automatically whenever the Jar changes, but changes to the target structure aren’t currently detected.

5

This is a serious issue since this means one can not trust the output of our CI server unless you run a clean before every build. Not having to do this is one of the major features of Gradle.

  1. Can you create/provide a tracker issue for this bug? 2. Is this limitation documented in the DSL or user guide? 3. Does this bug extend to other tasks such as Copy or others?
6

Please see http://issues.gradle.org for related issue(s). This is a limitation of all tasks that use copy specs, and to my knowledge it is only documented in JIRA. I’m aware of at least one other case where a build script change that may change the output of a task currently goes undetected, namely when changing the implementation of an ad-hoc task action. Having completely fool-proof up-to-date checks is a definite goal, but at this time, I recommend to run a clean build whenever absolute correctness is paramount and no room for error exists (release builds, possibly other CI builds).

7

Can’t this be solved by making all copy tasks have an input dependency on the gradle file?

8

Only to some extent, and it would be too coarse-grained. A better solution is needed.