使用持续集成 Gradle 多模块依赖项

Question

刚从 Android Studio/Gradle/CI 开始，我有一个 Android Studio 项目设置，其结构类似于：

┌ Project
│
├── Module "lib-core" (produces .aar)
│  
├── Module "lib-v1" (produces .aar, depends on "core-lib")
│  
├── Module "lib-v2" (produces .aar, depends on "core-lib")
│  
├── ... (potentially mode libs)
│  
└── Module "test-app" (produces .apk, depends on "lib-v1" and "lib-v2")

“lib-core”只能在本项目内部直接使用，而“lib-v1”和“lib-v2”也可以在其他项目中使用（“test-app”是一个示例项目来展示用法“lib-s”) 并且需要作为 aar-s 在我们的 Maven 存储库中。

该项目也是使用 Jenkins 构建的，并且工件会转到本地 Maven 存储库 (Sonatype Nexus)。这是通过“assembleRelease uploadArchives”任务实现的。作为 CI 的一部分，项目需要相应地进行版本控制。理想情况下，所有 lib 模块（实际上是它们的工件）都应该保持相同的版本。

现在解决这个问题：假设我已将版本升级到 1.4.2。现在，当 Jenkins 尝试评估构建脚本时，它抱怨版本 1.4.2 的“lib-core”还不存在，这是真的。在这种情况下，“lib-v1”将通过 'compile“org.example:lib-core:1.4.2@aar”' 依赖于“lib-core”

另一方面，如果 "lib-v1" 通过 'compile project(":lib-core")' 声明对 "lib-core" 的依赖，则在 Nexus-repo 上生成的 pom.xml（对于“lib-v1”）不包含对“lib-core”的正确引用......不幸的是，我目前无权访问样本，但如果我没记错的话，groupId 是“未解决”行， “未指定”或类似的。所以在这种情况下，“lib-v1”不能在管道中进一步使用（使用 {transitive = true } 来解析“lib-core”）

有没有办法设置构建脚本，以便构建“lib-core”并在评估其他模块之前上传其工件，但不将其拆分为多个项目？或者其他一些可以在开发者机器和 CI 服务器上构建这个项目的设置方式？

不知何故，我似乎把事情复杂化了，这可以通过其他（简单）方式来完成，我只是目前没有看到它。

编辑

当我使用 'compile project(":lib-core")' 声明依赖项时，我会在 pom.xml 中为 Nexus repo 上的 "lib-v1" 获得以下内容：

<dependency>
<groupId>Library</groupId>
<artifactId>lib-core</artifactId>
<version>unspecified</version>
<scope>compile</scope>
</dependency>

artifactId 是正确的，但是 groupId 是模块名称，而版本是“未指定” - 所以使用“lib-v1”的项目无法解析“lib-core”依赖。

Answer 1

我认为不可能“在评估其他模块之前构建并上传其工件”，因为 gradle 必须在“执行”短语之前完成“配置”短语在“配置”短语期间，gradle 将尝试评估所有模块中的所有依赖项。

但是，“通过 'compile project(":lib-core")' 声明对 "lib-core" 的依赖项" 应该适合您，并且我们有与您类似的设置，可以正常工作。您的 build.gradle 中的模块 gradle/version 可能有问题。如果您可以提供更多详细信息，例如pom.xml 和 build.gradle，会更清晰。

您能否尝试在项目级别的 build.gradle 中关注。

allprojects {
    group = 'Library'
    version = '1.4.2.'
}