两者之间有什么区别吗？
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
就我而言，这两项行动的结果应该是一样的。
然而，在每种情况下，行为似乎都不同：前者似乎更广泛;后者更快结束 - 我正在努力理解为什么会这样。
让我们首先澄清一下有关多模块（聚合器）构建（即，从聚合器/父项目调用构建）和构建单个模块的内容。
我们使用以下示例：
-+ modules-project
|- module-a
|- module-b (depends on module-a)
因此，模块项目将作为其pom的一部分具有以下内容：
<modules>
<module>module-a</module>
<module>module-b</module>
</modules>
从module-project文件夹构建时：
module-project> mvn clean install
Maven Reactor将创建声明模块的依赖关系图并相应地构建它们，因此module-a将在module-b之前构建，因为module-b依赖于module-a
module-b> mvn clean install
可以正常工作，只构建module-b，将模块-a解析为依赖项（我们之前安装过），并在需要时将其作为构建类路径的一部分。
如果不是在modules-project上调用clean install，我们就会调用clean package，Maven不会在我们的本地Maven缓存中安装任何东西，因此无法解析module-b项目中对module-a的依赖。澄清：
module-project> mvn clean package
仍然会构建整个项目（包含所有子模块）并创建包（即jar文件）。
module-b> mvn clean package
现在会失败，因为对本地Maven缓存或任何Maven存储库中不存在对module-a的依赖，也就是说，它不作为依赖存在而且Maven对其他模块一无所知，它正在构建一个简单的项目（模块），不了解其他模块（由modules-project提供）。当构建模块项目时，Maven正在构建具有更多信息的每个模块，知道模块与另一个模块的依赖关系，它不会在本地缓存或任何Maven存储库中查找模块间依赖关系。再次，它是一个reactor build。
这就是为什么只有在已经构建整个多模块项目并且至少在本地Maven缓存中安装其工件时，才能将子模块构建为单独的构建。这就是为什么最佳实践始终是从多模块项目开始工作，以便Maven拥有所有必需的信息，您可以：
mvn clean install）-pl选项构建单个或一组模块（但仍然从多模块项目开始）-pl和-am选项构建单个或一组模块及其依赖项（仍然来自多模块项目）我们现在澄清最后一点，它也将回答你的问题。
modules-project> mvn clean package -pl module-a
运行正常，只构建模块-a作为反应堆构建的一部分。然而
modules-project> mvn clean package -pl module-b
会失败，因为Maven将按照要求尝试构建module-b，但是，再次，将查找模块-a作为依赖项而不是模块，因此在本地Maven缓存或配置的Maven存储库中，找不到它。
modules-project> mvn clean package -pl module-b -am
最终会工作正常，因为现在Maven也在构建依赖模块（感谢-am）并且确切地知道在哪里找到它们（作为多模块信息的一部分，即modules部分）。
让我们看看最后一个案例：
module-b> mvn clean package -am
如果我们从未安装整个多模块项目（即我们总是运行clean package）会失败，如果不是反应堆构建的一部分，-am选项将被忽略（因为它是reactor的选项，而不是正常构建）和Maven仍然会尝试在本地缓存或存储库中找到module-a。
这就是为什么你应该总是从它的聚合器/父和通过-pl和-am选项构建一个子模块，以确保：
这也是为什么你的观察是正确的，你提到的第一个调用（从聚合器项目构建一个子模块）需要稍长一些，因为它不仅仅是子模块的构建，而是更多（因为有更多的信息需要处理，它是一个不同类型的构建，一个反应堆，也可能构建依赖模块），而直接构建一个子模块（从其目录）是一个更简单的Maven构建，因此也更快（但由于缺少一些信息，更容易出错）。
有关这些反应堆构建选项的更多信息可以在here找到。