Maven parent pom vs modules pom

在我看来，要回答这个问题，你需要从项目生命周期和版本控制的角度来思考。换句话说，父 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:externalstrunks

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

然后，检出 将产生以下本地结构（模式 #2）：trunks

root/
  parent-pom/
    pom.xml
  projectA/

（可选）您甚至可以在目录中添加一个：pom.xmltrunks

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

这是一种“假”pom：它从未发布过，它不包含真实版本，因为此文件从未发布过，它只包含模块列表。使用此文件，签出将产生以下结构（模式 #3）：pom.xml

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

这个“黑客”允许在结帐后从根部启动反应堆构建，并使事情变得更加方便。实际上，这就是我喜欢为大型构建设置 maven 项目和 VCS 存储库的方式：它工作正常，扩展良好，它提供了您可能需要的所有灵活性。

如果答案是否定的（回到最初的问题），那么我认为你可以接受模式#1（做可能起作用的最简单的事情）。

现在，关于奖金问题：

• 在源代码管理，部署目录，通用插件等中定义各种共享配置的最佳位置在哪里（我假设是父级，但我经常被这个咬伤，它们最终出现在每个项目中，而不是一个普通的项目中）。

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

• maven-release插件，hudson和nexus如何处理你如何设置你的多项目（可能是一个巨大的问题，如果有人在如何设置多项目构建时被抓住，那就更多了）？

我使用的设置效果很好，没什么特别值得一提的。

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

根据我的经验和Maven最佳实践，有两种“父母poms”

• “公司”父 pom - 此 pom 包含您公司的特定信息和配置，这些信息和配置继承每个 pom，不需要复制。这些信息是：

  • 存储 库
  • 分发管理部分
  • 常见插件配置（如 maven-compiler-plugin 源版本和目标版本）
  • 组织、开发人员等

  准备这个父pom需要谨慎完成，因为你公司的所有pom都会从中继承，所以这个pom必须成熟和稳定（发布父pom的版本不应该影响发布所有公司项目！

• 第二种父 pom 是多模块父项。我更喜欢您的第一个解决方案 - 这是多模块项目的默认maven约定，通常表示VCS代码结构

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

多个项目具有树的结构 - 因此您不会被向下箭头到父 pom 的一个级别。尝试找到适合您需求的项目结构 - 一个经典的例证是如何区分多个项目

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

一些奖励问题：

• 在源代码管理，部署目录，通用插件等中定义各种共享配置的最佳位置在哪里（我假设是父级，但我经常被这个咬伤，它们最终出现在每个项目中，而不是一个普通的项目中）。

此配置必须明智地拆分为“公司”父 pom 和项目父 pom（ s）。与你所有项目相关的事情转到“公司”父级，与当前项目相关的内容转到项目一个。

• maven-release插件，hudson和nexus如何处理你如何设置你的多项目（可能是一个巨大的问题，如果有人在如何设置多项目构建时被抓住，那就更多了）？

公司母公司pom必须首先发布。对于多项目，标准规则适用。CI服务器需要知道所有内容才能正确构建项目。