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

• SSN通讯模块
• 等通讯模块
• 路由器模块
• 投票收集器子模块进行投票
• 等进行投票
• 测验服务模块
• 等模块

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

一种是使用树结构，就像前一种一样。这种结构的缺点是我们需要进行大量的调整/修改才能使多模块报告与Maven一起正常工作。另一个缺点是，在Subversion中，标准的主干/标签/分支方法使存储库更加复杂。

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

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

解决方案

回答

我认为我们最好平整目录结构。也许我们想为目录起一个命名约定，以便在查看所有项目时它们可以很好地排序，但是最终我认为不需要所有额外的层次结构。

假设我们正在使用Eclipse作为IDE，那么无论如何导入它们，所有项目都将最终归入一个平面列表，因此我们从其他子目录中实际上不会获得任何收益。除了配置非常简单之外，没有所有额外的层次结构，这使得选择在我心中非常清晰。

我们可能还需要考虑合并某些模块。我对应用程序或者域一无所知，但似乎其中许多叶级模块可能更适合作为另一个顶级模块中的软件包或者一组软件包使用。我全力以赴，保持罐子的凝聚力，但有时可能太过分了。

回答

我们有一个比较庞大的应用程序(160多个OSGi捆绑软件，其中每个捆绑软件都是Maven模块)，并且我们继续学习的经验教训是，扁平化是更好的选择。在层次结构中编码语义的问题是我们失去了灵活性。今天100％说"通信"的模块明天可能会部分"服务"，然后我们需要在存储库中四处移动，这将破坏各种脚本，文档，参考资料等。

因此，我建议使用扁平结构，并在另一位置对语义进行编码(例如，IDE工作区或者文档)。

我已经用另一个示例详细回答了有关版本控制布局的问题，这可能与情况有关。