Gradle monobuild 和所有 gradle 复合构建的 jar 文件映射答案

【问题标题】：Gradle monobuild and map of jar files for all gradle composite buildsGradle monobuild 和所有 gradle 复合构建的 jar 文件映射
【发布时间】：2020-12-05 19:53:34
【问题描述】：

我们有一个这样的目录结构

Java
- build/build.gradle（这还不存在，但我们想要这个）
- 服务器
  - server1/build.gradle
  - server2/build.gradle
- 库
  - lib1/build.gradle
  - lib2/build.gradle

我们有 11 台服务器和 14 个库，它们使用不同的依赖项。每个服务器都是仅依赖于库的复合构建（我们不允许服务器相互依赖）。这样，随着我们的 mono-repo 的增长，随着越来越多的 gradle 代码的添加，打开 server1 并不会变得越来越慢（即 gradle 只加载 server1 及其所有库，而其他库或服务器都没有加载保持事情很快）。

好的，所以我们现在遇到的一个问题是重复，这就是为什么我们需要 build/build.gradle 文件并且我们希望我们的 mono repo 中的每个模块都以某种方式包含一些目标（每个目标可能需要不同的解决方案）

目标 1：拥有一个包含字符串 Map 的 ext { ... } 部分，以像这样对依赖项进行分级

deps = [
  'web-webserver':      "org.webpieces:http-webserver:${webpiecesVersion}",
  'web-webserver-test': "org.webpieces:http-webserver-test:${webpiecesVersion}",
  'web-devrouter':      "org.webpieces:http-router-dev:${webpiecesVersion}"
]

通过这种方式，我们希望我们所有的项目都像这样导入依赖项

compile deps['web-webserver']

目标 2：我们希望“包含”一个标准的插件列表，因此我们在 repo 中对所有 gradle 插件进行相同的版本控制。虽然上面配置了所有 jars 以避免在 mono-repo 中出现 jar hell，但我们希望仅在本节中做同样的事情

plugins {
  id 'com.github.sherter.google-java-format' version '0.9'
}

当然，每个项目可能还想添加更多插件，或者甚至不依赖此部分（以防紧急情况并试图完成工作）。

目标 3：我们希望为所有项目定义相同的 checkstyle 配置（或任何插件配置）（最终！！！）。我们希望 checkstyle gradle 位于一个公共区域，但所有库都以某种方式将其拉入。同样，如果它是可选的，那就太好了，我可以将 gradle 部分拉到我的 build.gradle 中，或者可以创建一个紧急情况下新的，所以我不必立即修复 monorepo 中的所有项目。

理想情况下，也许我有点想要配置注入，当我运行 server1/build.gradle 时，它实际上运行 java/build/build.grade，因为它是父级，但有覆盖（如果我声明“扩展 xxx.gradle”可能) 然后它使用的所有库也使用 java/build/build.gradle 作为它们的父级。我不确定这是可能的还是可行的。我很确定 gradle 中不存在“扩展 xxx”。

这些目标中的任何一个都有可能吗？

谢谢，院长

【问题讨论】：

标签： gradle checkstyle

【解决方案1】：

我有点困惑，为什么您不只使用“标准”gradle 顶级构建文件并将其他文件组合为subprojects。这解决了您的所有 3 个目标

如果您担心构建速度，您可以通过运行单独定位每个服务器

./gradlew :server1:build

但如果由于某种原因您无法执行此操作，您可以使用 apply from: 语法，如 here 所述

【讨论】：

因为在 100 台服务器、187 个库中，每个开发人员的加载时间 == 慢得像废话（即，该解决方案不能很好地扩展）。如果您在一个所有项目都在一个 git 中的 monorepo 中工作，那么当您只加载团队所需的内容时，这真是太棒了。如果你加载得更像你说的那样，事情会变得非常慢，非常快。 @h3adache。 monorepo 做得比人工制品做得更好，人们往往会不小心破坏其他团队（这实际上是不可能的，正确的 monorepo 设置可以消除那里的很多问题）。
Twitter 运行一个更大的 monorepo。我什至研究了 gradle（推特使用裤子），但 gradle 对大规模真正的 monorepo 的支持还没有真正到位。我认为越来越多的人会做出改变（我知道我是在 FAST monorepo 工作后做到的......这太棒了）
我在上面的回答中提到的apply from: 方法将起作用。它允许您组合构建，同时保持每个“子存储库”分开。
太棒了！！！我错过了最后一句话。天哪，如果这行得通，那就太恶心了。谢谢！！！！我希望我可以将所有 3rd 方 jar 压缩到一个用于 mono-repo 的 gradle 文件中（是的，当有人升级 jar 时，它会一次性完成所有库和服务）。

【解决方案2】：

我一直在开发一个与您要求完全相同的 monorepo，也使用 gradle 复合构建。我们解决这个问题的方法是使用pre compiled plugins

您需要仅使用要共享的代码来创建一个新的 gradle 项目。这将创建一个插件，您可以将其添加为复合构建并应用于其他项目。

【讨论】：