Gradle Copy任务优化：延迟依赖配置解析至执行阶段及相关疑问解答

我编写了如下Gradle任务：

task copySomething(type: Copy) {
    dependsOn configurations.myConf
    into "build/something"
    from(zipTree(configurations.myConf.asPath)) {
        include "*.sql"
    }
}

该任务可正常运行，但会在Gradle构建的配置阶段解析myConf依赖配置，导致无法在build.gradle的后续代码中为myConf添加更多依赖（触发错误：Cannot change dependencies of dependency configuration ':my-project:myConf' after it has been resolved.）。

请问如何创建一个仅复制配置内容，但不在配置阶段解析myConf（改为在执行阶段解析）的任务？另外，dependsOn configurations.myConf的实际作用是什么？根据我的使用经验，它似乎不会在任务执行前解析该配置，也没有明显效果。

一、实现执行阶段解析配置的Copy任务 #

问题根源在于你直接在from块里调用了configurations.myConf.asPath——这个操作会在配置阶段就触发配置的解析。要延迟到执行阶段，咱们可以用Gradle的延迟求值能力，这里有两种实用方案：

方式1：用project.provider()延迟构建zipTree #

这是最推荐的方案，既能保留Copy任务的增量构建特性，又完美实现延迟解析：

task copySomething(type: Copy) {
    into "build/something"
    // 用provider包装逻辑，直到任务执行时才会解析myConf
    from(project.provider {
        zipTree(configurations.myConf.asPath)
    }) {
        include "*.sql"
    }
    // 显式声明依赖，确保myConf在任务执行前完成解析
    dependsOn configurations.myConf
}

provider会把内部的逻辑包装成一个懒加载对象，只有当任务真正要执行复制操作时，才会调用configurations.myConf.asPath，此时配置阶段已经结束，你完全可以在后续代码中给myConf新增依赖。

方式2：在doFirst闭包里动态执行复制逻辑 #

如果你更习惯命令式写法，也可以把复制逻辑放到任务的doFirst闭包中——这个闭包只会在执行阶段运行：

task copySomething {
    doFirst {
        copy {
            from(zipTree(configurations.myConf.asPath)) {
                include "*.sql"
            }
            into "build/something"
        }
    }
    dependsOn configurations.myConf
}

不过这种方式会丢失Copy任务内置的增量构建优化（比如只复制变更文件），所以优先选择第一种方案。

二、dependsOn configurations.myConf的实际作用 #

你觉得它没效果，是因为原来的代码里from(zipTree(configurations.myConf.asPath))在配置阶段就提前触发了解析，把dependsOn的作用给掩盖了。其实它的作用很明确：

当你把一个配置传给dependsOn时，Gradle会自动让当前任务依赖于该配置的resolve任务（比如自动生成的resolveMyConf任务）。这个依赖会确保：

1. 在你的copySomething任务执行前，myConf已经完成解析流程——包括下载依赖、处理依赖冲突、生成最终的依赖文件列表等操作。
2. 它本身不会触发配置阶段的解析，只有当代码调用了配置的resolve()、asPath等需要实际获取依赖内容的方法时，才会触发解析。

如果去掉这个dependsOn，Gradle在执行阶段解析myConf时也会自动处理依赖关系，但显式声明依赖会让构建逻辑更清晰，还能避免并行构建时可能出现的资源竞争问题。

内容的提问来源于stack exchange，提问作者mzakrze