首页 / 知识

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

2023-04-12 18:03:00

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

Repository layout for large Maven projects

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

  • 应用

    • 通讯模块

      • 彩色通讯模块
      • SSN通讯模块
      • 等通讯模块
    • 路由器模块
    • 服务模块

      • 投票服务模块

        • 用于投票的Web界面子模块
        • 投票收集器子模块进行投票
        • 等进行投票
      • 测验服务模块
      • 等模块

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

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

另一种方法是使用扁平结构,其中只有一个父项目,而所有模块,子模块和部分子模块都是父项目的直接子代。这种方法非常适合报表生成,在Subversion中更容易实现,但是我觉得这种方式会使我失去一些结构。

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


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

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

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


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

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

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


模块布局项目服务

最新内容

相关内容

热门文章

推荐文章

标签云

猜你喜欢