zipTree using Groovy with Gradle3.1

Old Forum Archive Bugs
1

We have been using gradle copy task with zipTree inside it and since we have updated to latest gradle3.1 version, it starts to throw an error about not being able to unzip the files and hence wont copy to destination.

I have verified it using older gradle(2.14) and it just unzips as expected.

Here is the snippet of what we have been using,
project.tasks.create(name: “myCopyTask” , type: Copy){
from project.zipTree(file)
into destination

}

2

Hi,

Just trying this on OS X with an arbitrary zip file works for me.

Can you please share some more information about your build and your environment?
If you can, please provide build scans: https://scans.gradle.com/get-started?type=project (of both the working and the failing variants)

You may also check if it is a daemon related problem. The daemon was turned on by default with 3.0+ and you might have started to use it without noticing. Please check if it is still broken when running with --no-daemon.

3

Thanks for responding. So, i have tried using --no-daemon and i still get the same error.
We are using plugins to run our multicomponent project and we have dependencies for custom configurations. We are staging the extracted files to a specific folder for which we are using above copy task.

Fyi…there is an issue while i just try to copy jars to destination as well. However, i have worked around it for now.

Here is the scan report i have generated
https://scans.gradle.com/s/66adqinzqcubc

4

sorry, the above scan report is for the failure case(using gradle 3.1) and here is the one which is passing the staging task using older version(2.14). this report still fails at artifactoryPublish for missing file(dont have to worry about this).

https://scans.gradle.com/s/dyujnqauppfxo

5

We discovered a regression in 3.0/3.1 which might also be the cause for this (GRADLE-3568). Do you make any use of rename in your copy task? Can you check if the issue is still reproducible with the latest nightly? (gradle-nightly-build)

6

we are using rename closure this way…

def copyConfig(Project project , String destination , Closure renameClosure={} ){
def copyTask = project.tasks.create(name: “myCopyTask” , type: Copy){
from project.zipTree(file)
into destination
rename renameClosure
}
return copyTask
}

And i have tried using the nightly build snapshot version of gradle distribution, and it works as expected. Are you planning for including this change in next release?

7

Happy to see that this fixed your problem as well. And yes this fix will be in Gradle 3.2 for which we have already started to prepare.

A workaround to make your script work with Gradle 3.1 is to make sure that your renameClosure never returns “null”. E.g. by returning the original name in case of “null” (which was the behaviour before it broke).

8

Thanks. Yes, i think i have used similar workaround.