返回

Ionic Android 构建报错:Plugin not found 解决方案

Android

Ionic Android 构建报错:Plugin not found (org.jetbrains.compose)

最近在构建一个 Ionic 应用的 Android 版本时遇到了一个挺麻烦的问题。本地构建、生成 APK 文件一切正常,但一放到 CI/CD 环境中就报错。报错信息如下:

FAILURE: Build failed with an exception.
* Where:
Script '/builds/haleoclinic/private/frontend-vue/node_modules/cordova.plugin.zoom/src/android/build-extras.gradle' line: 2
* What went wrong:
A problem occurred evaluating script.
> Plugin with id 'org.jetbrains.compose' not found.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 31s

更奇怪的是,一两周前相同的代码和构建流程还能正常工作。问题出在 cordova.plugin.zoom 这个插件的 build-extras.gradle 文件上:

apply plugin: 'org.jetbrains.compose'
apply plugin: 'kotlin-android'
// ... 省略其他代码 ...

问题原因分析

错误信息很明确:“Plugin with id 'org.jetbrains.compose' not found”。这意味着 Gradle 在构建过程中找不到 org.jetbrains.compose 这个插件。通常,构建脚本里有了 apply plugin: '...' 语句,Gradle 会自动下载并应用所需的插件。但现在的情况是,CI/CD 环境中没有成功获取到这个插件。

可能的原因有以下几点:

  1. 网络问题: CI/CD 服务器可能无法访问 JetBrains 的插件仓库,或者网络连接不稳定,导致下载失败。
  2. Gradle 版本: 项目的 Gradle 版本可能与 org.jetbrains.compose 插件不兼容。
  3. 插件版本: org.jetbrains.compose 插件本身可能有 bug,或者需要特定版本的 Gradle 才能正常工作。
  4. CI/CD 环境配置: CI/CD 环境可能缺少必要的构建工具或依赖,例如 Kotlin、Compose 相关的库。
  5. 缓存问题: 可能是 CI/CD 缓存了旧的、有问题的构建配置或依赖项。
  6. build-extras.gradle 被错误修改 。虽然你说你回退了, 但是不排除还是被错误修改的可能性。

解决方案

针对以上可能的原因,我尝试了不同的方法,最终解决了问题。以下是具体步骤和思路:

1. 检查并修复 build-extras.gradle 文件

虽然你说代码已经还原了, 但为了以防万一, 强烈建议仔细查看插件中的 build-extras.gradle,确保它没有被意外修改。尤其要注意:

  • apply plugin: 'org.jetbrains.compose' 这一行是否正确。
  • 文件的路径是否正确,确保 CI/CD 环境能正确找到这个文件。

这一步是基本保障,如果文件没问题,继续往下看。

2. 确保网络连接正常

由于报错是在 CI/CD 环境,首先确认 CI/CD 服务器的网络连接是否正常,能否访问外部资源,尤其是 JetBrains 的相关仓库。

  • 可以在 CI/CD 的构建脚本中添加一些网络测试命令,比如 pingcurl 来检查网络连通性。
  • 如果你用的是例如 Github Actions 这种, 你可以在 step 里面执行 ping google.com

3. 添加插件仓库

即使 build-extras.gradle 文件中包含了 repositories 代码块,有些情况下还是会找不到插件。可以尝试在项目的根目录下的 build.gradle 文件 (注意不是 app 目录下的) 的 buildscriptallprojects 部分添加 JetBrains 的插件仓库:

buildscript {
    repositories {
        google()
        mavenCentral()
        maven { url "https://maven.pkg.jetbrains.space/public/p/compose/dev" } // 添加这一行
    }
    dependencies {
        // ... 其他依赖项 ...
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
        maven { url "https://maven.pkg.jetbrains.space/public/p/compose/dev" } // 添加这一行
    }
}

原理: 明确告诉 Gradle 去哪里找 org.jetbrains.compose 插件。

4. 显式声明插件依赖

如果添加仓库后仍然无效,可以尝试在项目的根目录下的 build.gradle 文件的 dependencies 部分显式声明对 org.jetbrains.compose 插件的依赖。 首先确定 org.jetbrains.compose 的版本. 然后在build.gradle中加入:

buildscript {
  // ...
    dependencies {
        // ... other dependencies ...
         classpath "org.jetbrains.compose:compose-gradle-plugin:1.5.10" // 替换为正确的版本号,不一定是1.5.10
    }
}

原理: 确保 Gradle 在构建项目之前就能获取到所需的插件。

版本号选择: org.jetbrains.compose的版本要慎重选择,因为它可能和你的Kotlin、Gradle版本有兼容性问题。 你可能需要查阅相关文档来确定适合你的项目的版本。
如果可以,直接到 build-extras.gradle的作者处查找版本依赖信息是最好的。

5. 调整 Gradle 版本(谨慎操作)

如果上述方法都不奏效,可以尝试调整 Gradle 版本。 注意:这是一个比较冒险的操作,因为 Gradle 版本的变动可能会影响到项目的其他部分。

  • 降低 Gradle 版本: 如果你最近升级过 Gradle,可以尝试回退到之前的版本,看看问题是否消失。
  • 升级 Gradle 版本: 有时候,较新版本的 Gradle 可能修复了与插件兼容性相关的问题。

修改 gradle/wrapper/gradle-wrapper.properties 文件中的 distributionUrl 属性来改变 Gradle 版本。例如:

distributionUrl=https\://services.gradle.org/distributions/gradle-7.4.2-bin.zip

原理: 不同版本的 Gradle 对插件的支持情况可能不同。

6. 清理并重建项目

有时候,Gradle 的缓存或构建产物可能会导致一些奇怪的问题。可以尝试清理项目并重新构建:

./gradlew clean
ionic cordova build android

原理: 清除旧的构建产物,强制 Gradle 重新下载和构建依赖。

7. 检查 CI/CD 环境配置

确保 CI/CD 环境中安装了正确版本的 Java、Kotlin、Android SDK 等构建工具,并且配置正确。不同的 CI/CD 工具配置方法不同,请查阅其官方文档进行配置.

8. 终极方案(如果以上都不起作用) -- 修改插件源码 (风险自担!)

因为这个是插件里面的错误, 如果你确定你的 build.gradle 没问题, CI/CD 的环境网络也没问题, 但又改不了CI/CD的环境配置(比如, 它是一个公司范围内所有团队共享的环境, 只有管理员能配置, 而你联系不上管理员, 或他拒绝修改). 并且迫切需要立刻构建和发布, 你可以选择修改这个插件的源码

找到出错的build-extras.gradle, 把apply plugin: 'org.jetbrains.compose'注释掉. 因为绝大多数情况下, 我们构建的都是发布版本, 而不是调试插件本身. 这样做可以让你绕过这个错误.

但是要注意 , 这相当于修改了插件的源码. 这会导致:

  1. 你没法再正常升级这个插件(除非插件作者自己修复这个问题).
  2. 你需要自己 fork 一份插件源码, 然后提交你自己的修改.
  3. 下次其他人或者 CI/CD 重新 clone 代码并且执行 npm install 时,又会遇到这个问题(除非你用了你修改后的插件)。

这虽然是个 hack, 但是它最直接, 最快速的让你跳过这个插件的错误, 继续构建和发布. 但我还是要强调: 这是万不得已的办法! 如果可能,尽量用前面7种方法解决。

总结

“Plugin not found” 问题通常与构建环境、依赖管理有关。解决这类问题需要耐心排查,逐一尝试不同的解决方案。修改别人的插件虽然是一种 hack, 但是要铭记 hack 的潜在风险。 仔细分析报错信息,结合项目的具体情况,通常能找到问题所在。