Java 大型Maven项目的存储库布局

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

• 应用
  • 通信模块
    • 彩色通信模块
    • SSN通信模块
    • 等通信模块
  • 路由器模块
  • 服务模块
    • 投票服务模块
      • 用于投票的Web接口子模块
      • 用于投票的投票收集器子模块
      • 等进行表决
    • 问答服务模块
    • 等模块

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

一种是使用与前一种相同的树结构。这种结构的缺点是，要使多模块报告与Maven一起很好地工作，您需要大量的调整/破解。另一个缺点是，在Subversion中，标准的trunk/tags/branchs方法会给存储库增加更多的复杂性

另一种方法使用平面结构，其中只有一个父项目，所有模块、子模块和子模块的部分都是父项目的直接子项目。这种方法在报告方面效果很好，在Subversion中更容易实现，但我觉得这样做会丢失一些结构

---

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

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

假设您使用Eclipse作为IDE，那么在导入项目后，所有项目都将以一个简单的列表结束，这样您就不会从额外的子目录中获得任何东西。除此之外，在没有所有额外层次结构的情况下，配置要简单得多，这使得我的选择非常清楚

---

您可能还需要考虑组合一些模块。我对您的应用程序或域一无所知，但似乎许多叶级模块更适合作为另一个顶级模块中的包或包集。我完全支持保持JAR的内聚性，但有时可能会走得太远。

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

因此，我建议使用平面结构，并在另一个地方（例如IDE工作区或文档）对语义进行编码

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