大型 Maven 项目的存储库布局

Question

我有一个大型应用程序（约 50 个模块），其结构类似于以下：

• 应用
  • 通讯模块
    • 彩色通讯模块
    • SSN 通讯模块
    • 等。通讯模块
  • 路由器模块
  • 服务模块
    • 投票服务模块
      • 用于投票的 Web 界面子模块
      • 投票收集器子模块
      • 等。投票
    • 测验服务模块
    • 等。模块

我想将应用程序导入 Maven 和 Subversion。经过一些研究，我发现有两种实用的方法可以解决这个问题。

其中一个与前一个一样使用树结构。这种结构的缺点是您需要大量的调整/修改才能使多模块报告与 Maven 一起工作。另一个缺点是在 Subversion 中，标准的 trunk/tags/branches 方法给存储库增加了更多的复杂性。

另一种方法使用扁平结构，其中只有一个父项目，所有模块、子模块和部分子模块都是父项目的直接子项目。这种方法适用于报告，并且在 Subversion 中更容易，但是我觉得这样我失去了一些结构。

从长远来看，您会选择哪种方式，为什么？

Answer 1

我们有一个较大的应用程序（160 多个 OSGi 包，其中每个包都是一个 Maven 模块），我们学到并继续学习的经验是扁平化更好。在你的层次结构中编码语义的问题是你失去了灵活性。一个今天 100% 说“通信”的模块明天可能部分是“服务”，然后你需要在你的存储库中移动东西，这会破坏各种脚本、文档、参考等。

所以我会推荐一个平面结构并在另一个地方编码语义（比如一个 IDE 工作区或文档）。

我已经详细回答了一个关于版本控制布局的问题with examples at another question，它可能与您的情况有关。

Answer 2

我认为你最好扁平化你的目录结构。也许您想为目录提出一个命名约定，以便在查看所有项目时它们可以很好地排序，但最终我认为所有这些额外的层次结构都是不必要的。

假设您使用 Eclipse 作为您的 IDE，一旦您导入它们，所有项目最终都会出现在一个平面列表中，因此您不会从额外的子目录中真正获得任何东西。除了没有所有额外层次结构的配置非常简单这一事实之外，这让我的选择非常清楚。

您可能还想考虑组合一些模块。我对您的应用程序或域一无所知，但似乎很多叶级模块可能更适合作为另一个顶级模块中的包或包集。我完全赞成保持罐子的凝聚力，但有时可能会走得太远。