持续集成和 Gradle: 外部项目作为依赖

Question

我有一个基于 Gradle 的项目，其中有一个外部项目作为依赖项。

settings.gradle

include ':app'
include ':mylibrary'
project(':mylibrary').projectDir = new File('/path/to/my/library')

我在开发 mylibrary 的同时开发我的应用程序，这就是我以这种方式将其包含在我的项目中而不是作为依赖项的原因（我必须在每个项目中上传工件将 jar 更改或复制到 libs 文件夹，这很乏味）。

我的问题是，当我提交我的应用程序更改时，Jenkins 构建失败，因为它找不到模块 mylibrary（显然，因为它在我的本地文件系统中）。

我该如何处理？

Answer 1

您应该在您的工作区中处理 2 个 gradle 个项目：

mylibrary
myapp（依赖于mylibrary）

修改 mylibrary 后，您应该对其进行测试，如果测试通过，则将其提交到源存储库和二进制存储库。（如果您不想手动执行此操作，您可以配置 3 个 Jenkins 作业，构建 <-- 测试 <-- 部署到二进制存储库，配置一个小的持续交付管道）。

接下来，当 mylibrary 被修改时，您应该对其进行测试，如果测试通过，则将其提交到存储库。这样的提交会触发 Jenkins 构建，因为 mylibrary 同时存在于源代码和二进制存储库中，它将成功编译。

您可以在版本 mylibrary 中采用 Semantic Versioning and managing the last version of mylibrary with graddle's Dynamic Versions or Changing Modules 功能。

Answer 2

我刚用这种方法解决了同样的问题

在 app 中添加 mylibrary 作为适当的依赖项。 app 构建将尝试从您配置的远程 Maven 或 Ivy 存储库中提取库。

当您更改 mylibrary 时，您可能希望立即让 app 看到该更改，而不是发布到二进制存储库。您可以使用 :mylibrary:publishToMavenLocal 任务完成此操作，该任务会将二进制库放入您的 ~/.m2/reposity 中。这只需要一个额外的命令，所以我认为还不错。这假设在 mylibrary:

中使用了新的 Maven 发布者

apply plugin: 'maven-publish'

接下来，app 需要指示从那里获取依赖项：

repositories {
    mavenLocal()
    //other repos
}

app:compileJava 任务现在应该首先检查您的本地 Maven 仓库，然后再检查远程仓库。

我发现这种方法比 taringamberini 的答案更可取，因为您不必发布对 library 尚未准备好供客户发布的更改。在将库更改合并到 master.

之前，您甚至可以测试对 mylibrary 的更改不会破坏 app

（您不想发布对二进制存储库的更改，这些更改不在 master 中。那将是灾难的根源...）

持续集成和 Gradle: 外部项目作为依赖

Continuous integration and Gradle: external project as dependency

continuous-integration

gradle