logo标签列表

大型Maven项目的仓库布局

javasvnmaven-2
15

我有一个大型应用程序（~50个模块），采用类似以下结构：

  • 应用程序
    • 通信模块
      • 颜色通信模块
      • SSN通信模块
      • 其他通信模块等
    • 路由器模块
    • 服务模块
      • 投票服务模块
        • 投票的Web界面子模块
        • 投票收集器子模块
        • 其他投票模块等
      • 测验服务模块
      • 其他模块等

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

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

另一种方法使用平面结构，其中只有一个父项目，而所有模块，子模块和子模块部分都是父项目的直接子级。该方法适用于报告，并且在Subversion中更容易，但我感觉这样会失去一些结构。

您会选择哪种方式并为什么？

2个回答
16
我们有一个相当大的应用程序（160个以上的OSGi bundle，每个bundle都是一个Maven模块），我们所学到的教训，并且仍在不断地学习，就是扁平结构更好。在层次结构中编码语义的问题在于你失去了灵活性。今天完全是"通信"的模块明天可能部分是"服务"，然后你需要在仓库中移动东西，这将破坏所有脚本、文档、引用等。
因此，我建议使用扁平结构，并在另一个地方（例如IDE工作区或文档）编码语义。
我曾详细回答过关于版本控制布局的问题，并在另一个问题中提供了示例，这可能与您的情况相关。
3

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

假设您使用Eclipse作为IDE，导入所有项目后它们都将最终以平面列表的形式呈现，因此您不会从额外的子目录中获得任何好处。除此之外，没有所有额外层次结构的配置使选择变得非常清晰。

您还可以考虑合并一些模块。我对您的应用程序或域一无所知，但是似乎有很多这些叶级模块更适合仅作为另一个顶级模块内的包或包集。我赞成保持jar文件的内聚性，但有时可能太过分了。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接