maven - 使用 maven -pl 选项和从模块级别运行 maven 有什么区别？

Question

有什么区别吗

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

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

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

Answer 1

让我们首先澄清一些关于多模块(聚合器)构建(即从聚合器/父项目调用构建)和构建单个模块的内容。
让我们使用以下示例:

-+ 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将创建声明模块的依赖图并相应地构建它们，因此模块 a 将在模块 b 之前构建，因为模块 b 依赖模块 a

module-b> mvn clean install

可以正常工作，只构建模块-b，将模块-a 解析为依赖项(我们之前安装过)，并在需要时将其用作构建类路径的一部分。
如果不是调用 clean install在模块项目上，我们会调用 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 提供)。相反，当构建模块项目时，Maven 正在构建具有更多信息的每个模块，因为知道一个模块对另一个模块有依赖关系，它不会在本地缓存或任何 Maven 存储库中查找模块间依赖关系。再次，这是一个 reactor build .
这就是为什么只有当您已经构建了整个多模块项目并至少在本地 Maven 缓存中安装了其 Artifact 时，您才能将子模块构建为单独的构建。这就是为什么最佳实践总是从多模块项目开始工作，以便 Maven 拥有所有必需的信息，您可以:

构建整个多模块项目 ( mvn clean install )

通过 -pl 构建单个或一组模块选项(但仍从多模块项目开始)

构建单个或一组模块 和 他们的依赖通过 -pl和 -am选项(仍然来自多模块项目)

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

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

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

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

会 失败 如果我们从未安装过整个多模块项目(即我们总是运行 clean package )，那么 -am如果不是 react 堆构建的一部分，则选项将被忽略(因为它是 reactor 的一个选项，而不是正常构建的一个选项)并且 Maven 仍会尝试在本地缓存或存储库中查找模块 a。
这就是为什么您应该始终从其聚合器/父模块并通过 -pl 构建子模块的原因。和 -am选项，以确保:

您使用正确的依赖项和模块信息正确构建

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

这也是为什么您的观察是正确的，您提到的第一次调用(从聚合器项目构建子模块)花费的时间稍长，因为它不仅仅是子模块的构建，而是更多的东西(因为有更多的信息要处理，它是一个不同类型的构建，一个 react 器，也可能构建依赖模块)，而直接构建子模块(从其目录)是一个更简单的 Maven 构建，因此也更快(但由于缺乏一些信息，更容易出错)。
有关 react 堆构建的这些选项的更多信息，请访问:

Maven Tips and Tricks: Advanced Reactor Options