java - 将 Java EAR 项目从 Maven 迁移到 Bazel？

Question

我有一个 Java Enterprise 应用程序，由多个模块(多个 WAR 和 JAR 以及 1 个 Angular5 模块)组成，这些模块已构建并打包到 1 个薄 EAR 中。

从功能角度来看，Maven 项目结构运行良好，一切都是模块化的，单元测试、集成测试等运行良好。

但是，由于构建速度的原因，我正在寻找 Maven 的替代方案，并且 Bazel 不断出现。

我安装了 Bazel，并遵循了简单的示例 JAR 教程，效果很好。在尝试规范并迁移到 Bazel 作为 POC 之前，我有一些问题:

1. 我的假设是否正确，即对于此类项目，使用 Bazel 可以比 Maven 显着提高构建速度？
2. 是否有使用 Bazel 构建 WAR 模块或 EAR 模块的示例？
3. 我的计划是，只要我正在试验，就将 BUILD 文件添加到 POM 旁边。这有什么缺点吗？
4. Bazel 看起来非常强大，因为它让我可以编写任何内容的脚本。这也可能是一个缺点，因为在 Maven 中，有太多的插件可以用于任何事情。对脚本或 Bazel 结构的可维护性有何想法​​？
5. 我在 Windows 而不是 Linux 上运行(是的..我知道)。 Bazel 有什么缺点吗？使用 MSYS2 似乎一切都运行良好且快速。

谢谢!我很想听听为 Java 企业应用程序实现 Bazel 的成功故事。

Answer 1

免责声明:我是 Bazel 团队的一名工程师。

Am I correct in my assumption that I can gain a significant build speed improvement with Bazel over Maven for this kind of project?

这将取决于您当前使用 Maven 构建的速度以及构建图的特征。

Redfin 公司去年从 Maven 迁移到 Bazel，其 CI 构建速度提高了 10 倍(从 40-90 分钟缩短到 5-6 分钟)。 They have documented this migration experience on their blog 。今年早些时候，Bazel 添加了对 remote caching 的支持，用户报告说这可以进一步加快他们的构建速度。

Are there examples to build a WAR module or EAR module with Bazel?

有 java_war packaging rule in rules_appengine 。 Bazel 是可扩展的，因此如果特定构建步骤的规则不存在，则可以将其写为 rule extension (例如this list of community rules)

My plan is to add the BUILD files next to the POMs as long as I am experimenting. Any downsides to that?

BUILD/BUILD.bazel 文件不会侵入您的项目，并且不应影响您现有的 Maven 构建。

Bazel seems ver powerful since it lets me script about anything. This may also be a downside, since in Maven there are so many plugins for about anything. Any thoughts on the maintainability of the scripts or Bazel structure?

这是一个非常主观的问题，这取决于您依赖的插件。

您可能遇到的一个迁移步骤是传递外部依赖项的管理。有一个很棒的工具，叫做 bazel-deps这可以帮助您管理它们并自动生成 BUILD 文件。

Jadep is another tool它会解析您的 Java 项目并为其生成 BUILD 文件。查看this guide了解有关 Jadep 的更多信息。

I am running on Windows instead of Linux (yes.. I know). Any downsides to that in relation to Bazel? Everything seems to work fine and fast with MSYS2.

Bazel 是 Windows 原生二进制文件，不依赖于 MSYS2 运行时，除非您使用依赖于 bash 的规则，例如 sh_library。查看此博文了解更多信息:https://blog.bazel.build/2017/10/16/windows-retrospect.html