How to deal with "Configuring child specs of a copy task at execution time of the task has been deprecated"

(Matthias Gärtner) #1

I wonder how to work around a warning that started to appear with Gradle 3.2 (we’re on Gradle 3.4.1.):

“Configuring child specs of a copy task at execution time of the task has been deprecated and is scheduled to be removed in Gradle 4.0. Consider configuring the spec during configuration time, or using a separate task to do the configuration.”

What we use is a Tar task that has some from clauses set at configuration time (good) and some others set at execution time (causing the warning). We do this because the set of resources to package up are not know (nor present) at configuration time. Most of the Tar content is created by the Gradle script, with the Tat being done at a later stage of execution.

I understand that the request to have from clauses only at configuration time stems from Gradle’s desire to do efficient and safe (!) up-to-date checks.

So one solution is to re-work that script portion to use the Ant tasks.
Could someone post an example for that mentioned alternative approach: “using a separate task to do the configuration” ? Thanks.

(James Justinic) #2

One example in the Gradle build is the configuration of the wrapper tasks that will automatically update to the wrapper to the current release, release client, or snapshot version.

That implementation is very dynamic with the definition of a closure that creates the task names, so here’s a simpler example specifically for a Tar task. The configureTar task can have much more logic if needed:

task configureTar {
    doLast {
        configure(tasks.'distTar') {
            from(someDynamicLocation) {
                include '*.jar'

task distTar(type: Tar) {
    dependsOn configureTar
    from "${buildDir}/staticLocation"

(uklance) #3

You can also use Project.copy(...) instead of a copy task.

task customCopy {
   doLast {
      if (foo) {
         copy {
            from 'foo' 
            into 'bar' 

(Matthias Gärtner) #4

Thanks James,
the reference to “configure(task)” in a dependency was what I was looking for.
I was able to change our build accordingly.