大型 Maven 项目的存储库布局

2022-09-03 14:13:20

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

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

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

一种是使用树结构,就像前一个一样。这种结构的缺点是,你需要大量的调整/黑客才能让多模块报告与Maven很好地配合使用。另一个缺点是,在 Subversion 中,标准的 trunk/tags/branch 方法给存储库增加了更多的复杂性。

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

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


答案 1

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

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

我已经详细地回答了一个关于版本控制布局的问题,并在另一个问题中提供了示例,它可能与您的情况有关。


答案 2

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

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

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


推荐