似乎有几种方法可以在多项目构建中构建父 pom，我想知道是否有人对每种方式的优点/缺点有任何想法。

拥有父 pom 的最简单方法是将其放在项目的根目录中，即

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

其中 pom.xml 既是父项目，也是描述 -core -api 和 -app 模块的地方

下一个方法是将父级分离到它自己的子目录中

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

父 pom 仍然包含模块但它们是相对的，例如../myproject-core

最后，可以选择将模块定义和父级分开，如下所示

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

父 pom 包含任何“共享”配置(dependencyManagement、属性等)，而 myproject/pom.xml 包含模块列表。

目的是可扩展到大规模构建，因此应该可扩展到大量项目和工件。

几个额外的问题:

• 在源代码控制、部署目录、常用插件等中定义各种共享配置的最佳位置是哪里？(我假设是父级，但我经常被这个问题困扰，它们最终出现在每个项目而不是普通项目)。
• maven-release 插件、hudson 和 nexus 如何处理您如何设置多项目(可能是一个巨大的问题，如果有人在如何设置多项目构建时被捕获，那就更重要了)?

编辑:每个子项目都有自己的 pom.xml，为了保持简洁，我把它省略了。

最佳答案

在我看来，要回答这个问题，你需要从项目生命周期和版本控制方面来考虑。换句话说，父 pom 是否有自己的生命周期，即是否可以与其他模块分开发布？

如果答案是是(问题或评论中提到的大多数项目都是这种情况)，那么父 pom 需要来自 VCS 和来自从 Maven 的角度来看，您最终会在 VCS 级别得到类似的结果:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

这使结帐有点痛苦，处理这种情况的常用方法是使用 svn:externals .例如，添加 trunks目录:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

具有以下外部定义:

parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk

结帐 trunks然后会产生以下局部结构(模式#2):

root/
  parent-pom/
    pom.xml
  projectA/

您甚至可以选择添加 pom.xml在 trunks目录:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

这个 pom.xml是一种“假”pom:它从未发布过，它不包含真实版本，因为该文件从未发布过，它只包含一个模块列表。使用此文件，结帐将产生此结构(模式 #3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

这种“hack”允许在结帐后从根目录启动 react 堆构建，并使事情变得更加方便。实际上，这就是我喜欢为 大型构建 设置 maven 项目和 VCS 存储库的方式:它可以正常工作，可以很好地扩展，它提供了您可能需要的所有灵 active 。

如果答案是否(回到最初的问题)，那么我认为你可以接受模式 #1(做可能可行的最简单的事情)。

现在，关于奖金问题:

• Where is the best place to define the various shared configuration as in source control, deployment directories, common plugins etc. (I'm assuming the parent but I've often been bitten by this and they've ended up in each project rather than a common one).

老实说，我不知道如何不在这里给出一个一般性的答案(比如“使用你认为有意义的水平来使事物相互化”)。无论如何，子 pom 总是可以覆盖继承的设置。

• How do the maven-release plugin, hudson and nexus deal with how you set up your multi-projects (possibly a giant question, it's more if anyone has been caught out when by how a multi-project build has been set up)?

我使用的设置效果很好，没有什么特别要提的。

实际上，我想知道 maven-release-plugin 如何处理模式 #1(尤其是 <parent> 部分，因为在发布时您不能拥有 SNAPSHOT 依赖项)。这听起来像是先有鸡还是先有蛋的问题，但我只是不记得它是否有效并且懒得测试它。

关于java - Maven 父 pom 与模块 pom，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1992213/