大型Maven项目的存储库布局

时间:2008-08-21 14:06:45

标签: java svn maven-2

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

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

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

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

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

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

2 个答案:

答案 0 :(得分:14)

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

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

我已经详细回答了有关版本控制布局的问题with examples at another question,这可能与您的情况有关。

答案 1 :(得分:3)

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

假设您正在使用Eclipse作为您的IDE,那么一旦您导入它们,所有项目都会以平面列表结束,因此您无法从其他子目录中获得任何结果。除了在没有所有额外层次结构的情况下配置如此简单的事实之外,我认为选择非常清楚。

您可能还想考虑组合一些模块。我对您的应用程序或域名一无所知,但似乎很多叶级模块可能更适合作为另一个顶级模块中的软件包或软件包集合。我只是为了保持罐子的凝聚力,但有时候它可能会走得太远。

相关问题