大型Maven项目的存储库布局

Question

我有一个大型应用程序(~50个模块)，它使用类似于以下结构的结构：

module

• 应用
  • 通信模块
    • 彩色通信模块
    • SSN通信模块
    • 等通信模块

​

- Router module
- Service modules  
    - Voting service module  
        - Web interface submodule for voting
        - Vote collector submodule for voting
        - etc. for voting

​

    - Quiz service module
    - etc. module

​

​

我想将应用程序导入Maven和Subversion。经过一些研究，我发现有两种可行的方法。

一种是使用树结构，就像前面的树结构一样。这种结构的缺点是，您需要大量的调整/黑客才能很好地完成Maven的多模块报告工作。另一个缺点是，在Subversion中，标准的主干/标记/分支方法给存储库增加了更多的复杂性。

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

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

Answer 1

我们有一个大型的应用程序(160+ OSGi包，每个包都是一个Maven模块)，我们学到并继续学习的教训是，这个平台更好。在您的层次结构中编码语义的问题是您失去了灵活性。今天100%说“交流”的模块可能是明天的部分“服务”，然后您需要在存储库中移动东西，这将破坏各种脚本、文档、引用等。

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

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

Answer 2

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

假设您使用Eclipse作为您的IDE，那么所有的项目在导入之后都会被放在一个单一的列表中，所以您实际上不会从其他子目录中获得任何东西。除了配置非常简单而没有所有额外的层次结构这一事实之外，在我的脑海中，选择也变得非常清晰。

您可能还需要考虑合并一些模块。我对你的应用程序或域名一无所知，但似乎很多叶级模块更适合作为其他顶级模块中的软件包或软件包。我完全赞成保持罐子的凝聚力，但有时候可能会太过分。