15

有没有区别

C:/dev/path/to/Project> mvn package -pl MyModule -am -s settings.xml

和

C:/dev/path/to/Project/MyModule> mvn package -am -s ../settings.xml

在我看来，这两个动作的结果应该是一样的。

然而，每种情况下的行为似乎都不同：前一种似乎更广泛；后者结束得更快 - 我试图理解为什么会这样。

4

1 回答 1

42

让我们首先澄清一下关于多模块（聚合器）构建（即从聚合器/父项目调用构建）和构建单个模块的一些事情。

让我们使用以下示例：

-+ modules-project
 |- module-a
 |- module-b (depends on module-a)

因此，modules-project 将在其 pom 中包含以下内容：

<modules>
    <module>module-a</module>
    <module>module-b</module>
</modules>

从模块项目文件夹构建时：

module-project> mvn clean install

Maven Reactor将创建已声明模块的依赖关系图并相应地构建它们，因此 module-a 将在 module-b 之前构建，因为 module-b 依赖于 module-a

module-b> mvn clean install

将正常工作，仅构建模块 b，将模块 a 解析为依赖项（我们之前安装）并在需要时将其用作构建类路径的一部分。

如果不是clean install在 modules-project 上调用 a ，而是调用 a clean package，Maven 就不会在我们的本地 Maven 缓存中安装任何东西，因此无法解析 module-b 项目中对 module-a 的依赖。澄清：

module-project> mvn clean package

仍将构建整个项目（及其所有子模块）并创建包（即 jar 文件）。

module-b> mvn clean package

现在会失败，因为对 module-a 的依赖不存在于本地 Maven 缓存中，也不存在于任何 Maven 存储库中，也就是说，它不作为依赖存在并且 Maven 对其他模块一无所知，它正在构建一个简单的项目（一个模块），不了解其他模块（由 modules-project 提供）。相反，当构建 modules-project 时，Maven 正在构建具有更多信息的每个模块，因为知道一个模块对另一个模块有依赖关系，它不会在本地缓存或任何 Maven 存储库中查找模块间依赖关系。同样，它是一个反应堆构建。

这就是为什么只有当您已经构建了整个多模块项目并至少在本地 Maven 缓存中安装了它的工件时，您才能将子模块构建为单独的构建。这就是为什么最佳实践总是从多模块项目中工作，以便 Maven 拥有所有必需的信息，您可以：

  • 构建整个多模块项目 ( mvn clean install)
  • 通过选项构建单个或一组模块-pl（但仍从多模块项目开始）
  • 通过and选项构建单个或一组模块及其依赖项（仍然来自多模块项目）-pl-am

现在让我们澄清最后一点，这也将回答您的问题。

modules-project> mvn clean package -pl module-a

运行良好，仅构建模块 a 作为反应堆构建的一部分。然而

modules-project> mvn clean package -pl module-b

会失败，因为 Maven 将根据请求尝试构建 module-b，但是，再次将 module-a 作为依赖项而不是模块查找，因此在本地 Maven 缓存或配置的 Maven 存储库中，找不到它。

modules-project> mvn clean package -pl module-b -am

最终会正常工作，因为现在 Maven 也在构建依赖模块（感谢-am）并且确切地知道在哪里可以找到它们（作为多模块信息的一部分，即modules部分）。

我们来看最后一个案例：

module-b> mvn clean package -am

如果我们从未安装过整个多模块项目（即我们总是运行）会失败，如果不是 reactor 构建的一部分（因为它是reactor的一个选项，而不是正常构建的一个选项），Maven 会仍然尝试在本地缓存或存储库中找到 module-a。clean package-am

这就是为什么您应该始终从其聚合器/父级并通过-pland-am选项构建一个子模块，以确保：

  • 您使用正确的依赖项和模块信息正确构建
  • 您针对最新版本的代码/依赖项进行构建，而不是针对您之前在 maven 缓存中安装的可能与其模块代码不一致的内容

这也是为什么您的观察是正确的，您提到的第一次调用（从聚合器项目构建子模块）需要更长的时间，因为它不仅仅是子模块的构建，而是更多（因为有更多信息要处理，它是不同类型的构建，一个反应堆，也可能构建依赖模块），而直接构建一个子模块（从其目录）是一个更简单的 Maven 构建，因此也更快（但由于缺少一些信息而更容易出错）。

有关反应堆构建的这些选项的更多信息，请访问：

于 2016-03-02T22:05:00.113 回答