大型Maven项目的存储库布局

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

应用

通讯模块

彩色通信模块

SSN通信模块

等通信模块

路由器模块

服务模块

投票服务模块

用于投票的Web界面子模块

投票收集器子模块进行投票

等投票

测验服务模块

等模块

我想将应用程序导入Maven和Subversion.经过一些研究后,我发现存在两种实用的方法.

一个是使用树结构,就像前一个一样.这种结构的缺点是你需要大量的调整/黑客才能使多模块报告与Maven一起工作.另一个缺点是在Subversion中,标准的trunk/tags/branches方法为存储库增加了更多的复杂性.

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

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

我们有一个很大的应用程序(160多个OSGi捆绑包,其中每个捆绑包都是Maven模块),我们学到并继续学习的经验教训是,平面更好.层次结构中编码语义的问题是您失去了灵活性.今天100%说"通信"的模块明天可能部分是"服务",然后你需要在你的存储库中移动东西,这将破坏各种脚本,文档,引用等.

所以我建议使用平面结构并在另一个地方编码语义(比如说IDE工作区或文档).

我已经回答了一个关于版本控制布局的问题,并在另一个问题上提供了示例,这可能与您的情况有关.