大型Maven项目的存储库布局 [英] Repository layout for large Maven projects

问题描述

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

I have a large application (~50 modules) using a structure similar to the following:

• 应用
  • 通讯模块
    • 彩色通讯模块
    • SSN通信模块
    • 等通讯模块
    • Application
      • Communication modules
        • Color communication module
        • SSN communication module
        • etc. communication module
        • 投票服务模块
          • 用于投票的Web界面子模块
          • 投票收集子模块
          • 等投票
          • Voting service module
            • Web interface submodule for voting
            • Vote collector submodule for voting
            • etc. for voting

            我想将应用程序导入Maven和Subversion.经过研究，我发现有两种可行的方法.

            I would like to import the application to Maven and Subversion. After some research I found that two practical approaches exists for this.

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

            One is using a tree structure just as the previous one. The drawback of this structure is that you need a ton of tweaking/hacks to get the multi-module reporting work well with Maven. Another downside is that in Subversion the standard trunk/tags/branches approach add even more complexity to the repository.

            另一种方法使用扁平结构，其中只有一个父项目，并且所有模块，子模块和子部分都是父项目的直接子代.这种方法对于报表效果很好，在Subversion中更容易实现，但是我觉得我失去了这种方式的结构.

            The other approach uses a flat structure, where there are only one parent project and all the modules, submodules and parts-of-the-submodules are a direct child of the parent project. This approach works well for reporting and is easier in Subversion, however I feel I lose a bit of the structure this way.

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

            Which way would you choose in the long term and why?

            推荐答案

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

            We have a largish application (160+ OSGi bundles where each bundle is a Maven module) and the lesson we learned, and continue to learn, is that flat is better. The problem with encoding semantics in your hierarchy is that you lose flexibility. A module that is 100% say "communication" today may be partly "service" tomorrow and then you'll need to be moving things around in your repository and that will break all sorts of scripts, documentation, references, etc.

            因此，我建议使用扁平结构，并在其他位置对语义进行编码(例如，IDE工作区或文档).

            So I would recommend a flat structure and to encode the semantics in another place (say for example an IDE workspace or documentation).

            我已经通过示例详细回答了有关版本控制布局的问题另一个问题，可能与您的情况有关.

            I've answered a question about version control layout in some detail with examples at another question, it may be relevant to your situation.

            这篇关于大型Maven项目的存储库布局的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！