【问题标题】:gradle custom task class makes itself uncompilablegradle 自定义任务类使自己无法编译
【发布时间】:2020-12-06 06:41:16
【问题描述】:

我正在尝试编写一个自定义 Gradle 任务类并在另一个子项目中使用它。我在将构建绑定在一起时遇到问题。

在此示例中,我将子项目命名为“a”(用于应用程序)和“p”(用于插件,虽然我没有使用插件对象,但只是为构建脚本提供了一个任务类)。

settings.gradle

include 'p'
include 'a'

p/build.gradle

apply plugin: 'java'
apply plugin: 'groovy'
apply plugin: 'maven-publish'

group 'test'
version '1.0'

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

dependencies {
    implementation gradleApi()
    implementation localGroovy()
}

p/src/main/groovy/p/MyTask.groovy

package p

import org.gradle.api.DefaultTask;
import org.gradle.api.tasks.TaskAction;

class MyTask extends DefaultTask {
    @TaskAction
    void run() {
        System.out.println('yay!');
    }
}

a/build.gradle

buildscript {

    repositories {
        mavenLocal()
    }

    dependencies {
        classpath 'test:p:1.0'
    }

}

group = 'test'
version = '1.0'

apply plugin: 'java'

task myTask(type: p.MyTask) {
}

“插件”是通过运行构建的,在 p 文件夹内:

../gradlew clean build publishToMavenLocal

a文件夹内:

../gradlew myTask

打印“耶!”

但是,在开发过程中,会发生错误。当我在 MyTask 中模拟一个错误时:

MyTask() {
    throw new RuntimeException("an error");
}

并构建插件(在文件夹 p 中):

../gradlew clean build publishToMavenLocal

按预期失败。

现在我通过再次删除损坏的构造函数来“修复”错误,并在文件夹 p 中重建:

../gradlew clean build publishToMavenLocal

但此命令失败并出现同样的错误。

据我了解,原因是:

  • 损坏的插件在我的本地 maven 仓库中
  • 尝试构建插件检测到父文件夹中的settings.gradle
  • gradle 尝试配置从 settings.gradle 引用的所有项目
  • 这会加载损坏的插件
  • 构建失败

为了验证,我注释掉了 settings.gradle 中的包含行,它又可以工作了。恢复 settings.gradle,它仍然有效,因为现在“固定”插件在我的 maven 存储库中,重建插件只会用工作版本再次覆盖它。

底线是我的自定义任务类(或自定义插件,或任何其他构建脚本代码)中的错误有可能使它们自己无法编译,解决方法是编辑或临时重命名 settings.gradle。项目越复杂,就越麻烦:如果插件代码本身包含多个子项目,重命名就不起作用,甚至注释掉变成“注释掉正确的行”。

解决此问题的预期方法是什么?

【问题讨论】:

    标签: gradle plugins multi-project build-script gradle-multi-project-build


    【解决方案1】:

    单个(多)项目的复杂逻辑最好在buildSrc 中组织。在大多数情况下,您可以将其视为普通的子项目,但仅用于构建类路径。您在此处创建的插件和任务自动可用于多项目中的所有项目。

    如果出于某种原因,您宁愿继续使用本地 Maven 存储库,您可以考虑发布带有版本号的插件的稳定版本,以便更容易回滚。

    【讨论】:

    • 这个问题是在开发插件时出现的,而不是稳定版本。 buildSrc 的问题是它就像一个单独的子项目,但是插件本身已经足够复杂,可以包含多个子项目。
    • 您可以在buildSrc 中拥有子项目(尽管根必须依赖它们)。您还可以将构建逻辑提取到独立项目中,并将其作为复合(包含)构建引入,这就是 buildSrc 的底层内容。我通常这样做是为了狗粮我自己的插件。关键是,如果要将其发布到存储库,则应使用版本号,以便在发生故障时始终可以回滚。如果您无法回滚到最新的稳定版,您可以在快照上使用时间戳。但我仍然发现第一个 buildSrc/composite 构建更易于维护。
    • 我怀疑复合构建最适合我的情况。您暗示 buildSrc 以更特别的方式做同样的事情,帮助我更好地搜索这方面的资源,所以这个答案+评论的组合解决了我的问题。
    猜你喜欢
    • 2017-07-14
    • 2015-12-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多