Java Maven父pom与模块pom

在多项目构建中，似乎有几种方法可以构造父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、properties等），myproject/pom.xml包含模块列表

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

一些额外的问题：

• 哪里是定义各种共享配置的最佳位置，如在源代码管理、部署目录、公共插件等中（我假设为父级，但我经常被这一点困扰，它们最终出现在每个项目中，而不是一个公共项目中）
• maven release插件、hudson和nexus如何处理您如何设置多项目的问题（这可能是一个巨大的问题，如果有人在多项目构建如何设置时被发现的话，这更重要）

编辑：每个子项目都有自己的pom.xml，为了简洁起见，我省略了它

独立父级是跨其他未耦合组件共享配置和选项的最佳实践。Apache有一个父pom项目来共享法律声明和一些常见的打包选项

如果您的顶级项目中有实际工作，例如聚合javadoc或打包发行版，那么您将在完成该工作所需的设置与希望通过父级共享的设置之间存在冲突。只有父项目才能避免这种情况

一种常见的模式（暂时忽略#1）是让带有代码的项目使用父项目作为其父项目，并让它使用顶级项目作为父项目。这允许所有人共享核心内容，但避免了#2中描述的问题

如果父结构与目录结构不同，站点插件将非常混乱。如果你想建立一个聚合站点，你需要做一些修改来解决这个问题

例如#2中的模式

---

根据我的经验和Maven的最佳实践，有两种“家长POM”

• “公司”父pom-此pom包含您公司特定的信息和配置，这些信息和配置继承每个pom，无需复制。这些资料包括：
  • 存储库
  • 分配管理科
  • 常见插件配置（如maven编译器插件源和目标版本）
  • 组织、开发人员等
  准备此父pom时需要谨慎，因为您公司的所有pom都将继承自此pom，因此此pom必须成熟且稳定（发布父pom版本不应影响发布您公司的所有项目！）

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

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

mutlipprojects具有树的结构，因此您不会将其分解为父pom的一个级别。试着找到一个适合你需要的项目结构——一个典型的例子是如何诋毁多模块项目

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

一些额外的问题：

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

此配置必须明智地划分为“公司”父pom和项目父pom。所有与您的项目相关的内容都将转到“公司”父级，而与当前项目相关的内容将转到项目一级

• maven release插件、hudson和nexus如何处理您如何设置多项目的问题（这可能是一个巨大的问题，如果有人在多项目构建如何设置时被发现的话，这更重要）

---

必须首先发布公司母公司pom。对于多项目，标准规则适用。CI server需要了解所有信息才能正确构建项目。

在我看来，要回答这个问题，您需要考虑项目生命周期和版本控制。换句话说，父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

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

具有以下外部定义：

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

然后，

中继的签出将导致以下局部结构（模式2）：

或者，您甚至可以在
trunks
目录中添加
pom.xml
：

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- 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：它从未发布过，它不包含真实版本，因为这个文件从未发布过，它只包含一个模块列表。与t