maven - 使用(maven)存储库和 Maven/Gradle 管理多个项目的最佳实践？

Question

这不完全是 Gradle 问题。但更一般的构建问题。我们有一些项目结构如下:

-- A  (by team 1)
  -- build.gradle
  -- settings.gradle
-- B (by team 1,3)
  --build.gradle
-- C (by team 2)
-- D (by team 3)

它们是独立的 CVS 模块。 A、B 和 D 是 java 项目，由两个团队(团队 1,3)管理。 C 是由另一个团队管理的 C++ 项目 (2)。 B 通过 JNI 使用 C。 (C是C++这个事实并不重要，关键是它是由另一个团队开发和管理的。)有两个应用程序，A是应用程序1的入口， A->B->C ;而 D 是应用程序 2 的入口点， D->B->C .发展通常涉及所有三个层面的变化。所有三个团队坐在一起并不断交流。在实践中，我们(团队 1)可能需要对 C 中的应用程序 1 进行一些更改；团队 2 在 C 上工作并给我们一个临时副本；集成后我们可能需要进行一些进一步的更改。我们会为了一个问题来回走几轮。同样适用于应用程序 2。

目前，A、B 和 D 由各种 ant 脚本管理，C 由 make 管理。我们开始探索新工具，尤其是 Gradle。在我们的第一个剪辑中，A 将 B 作为一个子项目(在 Gradle 意义上)，它们总是一起构建和发布。我们也总是使用 C 的头文件(从 windows 中的源代码自己编译或获取最新的 Jenkins 构建)，当我们对构建感到满意时，我们标记所有三个项目。我们最近采用了一个内部 Artifactory 存储库。我们正在考虑如何管理依赖和版本控制。完成后，我们也会将其介绍给模块 D 的团队 3。

我们可以尝试将 C 作为 A 的子项目，然后始终从头开始为所有三个构建。同样包括 C 和 B 作为 D 的子项目。例如，应用程序名称可以在版本名称中。

或者，我们总是可以依赖存储库中固定版本的 C。

在 2 中，我们不能完全依赖 C 的头部/快照，因为这可能涉及它们的开发并且可能不稳定。但是我们需要如此频繁地更改它们，以至于为每个 C 更改都放置一个新版本似乎是不切实际的。

我们想知道这种设置的最佳实践是什么？在互联网上快速搜索不会产生太多结果。谁能给我们一些建议或指点我一些书籍或文件？

非常感谢。

Answer 1

正如我从整个描述中看到的那样，似乎在开发期间(我想也在生产中)所有 3 个项目都非常紧密耦合。所以为了工作方便，我将使用第一个场景。我还将一起构建所有项目，将它们标记在一起并保持相同的版本控制模式 - 通常，即使它是分开的，这也是一个项目。

第一个场景可以持续到没有第 3 方(外部)应用程序/库/团队使用任何项目(我想它只能是 C 项目)。然后可能会发生向后兼容性问题/拉取请求和其他问题，并且应该将提到的项目分开。如果没有机会发生这种情况，您不应该过多打扰。但是请记住良好的(语义)版本控制，并标记存储库以始终确定哪个版本部署到哪个环境。

更新

问题更新后。

如果你有像 A->B->C 这样的依赖路径和 D->B->C我将重新组织项目结构。 B应该成为 A 的子项目和 D或者可能不是子项目，而是添加到这些项目的外部库。 B和 C应该是一个带有 B 的单独项目依赖于 C .

所有三个项目( A ， D ， B with C )都应该单独进行版本控制(尤其是 B with C )，因为这是客户的通用部分( A 和 D )。

现在，为了方便开发您可以添加到A和 D将经常在 CI 服务器上构建然后更新到 Artifact 的快照库。这将允许您对 B 进行更改。并让它们在项目中快速可见A和 D .但是 B 的稳定版本(因此 C )应该完全分开维护。

我希望我能很好地理解这个问题并帮助你一点。

附言请考虑使用 gitflow - 分支模型。然后您可以在 dev 分支中使用 SNAPSHOT 版本和 B 的稳定版本在释放。