What’s the reason behind wanting to disable the up-to-date check? IMHO this is not desirable. Could you please elaborate more on your problem description. I don’t understand the steps you are listing there.
The problem is that an empty zip task is ever UP-TO-DATE. There is no option to add the files on run first. There must be added a modified file in the configuration phase.
This produce multiple problems: * it is not possible to create an empty zip file * an old zip will not deleted if the input is empty. * add files dynamically is not possible
In my case I have downloaded the files from an external web server. First after the download I know which files need to added to the zip file. The download can not run in the configuration phase. It required the output of other tasks.
My workaround in the meantime is to call execute on a inner zip task. There are also other workarounds possible. But it will not change that the behavior is a bug. The major problem is that the old zip file will not deleted if the input is empty.
But was I does not understand why I can not override the upToDateWhen.
I am still a bit unclear about your use case. I think I’d need to see your code. Isn’t this what you are looking for - bundling a ZIP file by depending on the outputs of the downloaded task?
task plugin ( type: Zip ) {
outputs.upToDateWhen { false }
doFirst {
String fileName = xyz() // an external java tool that download and calcluate some things
if( fileName == null ) {
fileName = 'other'
}
from files( fileName )
}
}
To split this in 2 task is a also a solution. This is equals to my current solution. But this is not the topic. The topic is that an empty zip task is ever UP-TO-DATE. This is a bug. The next bug is that upToDateWhen will be ignored for a zip task.
Gradle is a very cool tool but some things does not work like expected. Of course there are workaround but to find this cost time.
Probably it will not work to change the source directory after the configuration phase. Indeed the copy task behaves just the same:
task myCopy(type: Copy) {
from 'non-existent'
into 'copied'
doFirst {
from(projectDir) {
include 'build.gradle'
}
}
}
This will always be UP-TO-DATE as well and not copy anything. An easy solution to this would be using the copy method, but unfortunately there is no zip method…
I am still very curious to know what is the contents of your ‘other’ file?
Putting the ‘from’ method call in an action is too late in the build lifecycle to configure the ‘Zip’ task. It needs to be resolvable during the configuration phase.
Best way to do things here would be to encapsulate your external java tool into a task of its own. Have it specify an output, and then zip up that output. Or if you really need it done all at once, have the download task put it into a zip.