我对在项目中使用存储库管理器缺乏一些基本了解。我不知道的是，如果我使用存储库管理器，如果我运行本地install命令，Maven如何不将包部署到共享Nexus实例中。在使用存储库管理器时，我似乎对本地存储库和共享存储库有一些混淆。
为我的天真和没有亲自测试而道歉。我们已经开始对我们的应用程序进行版本控制，并使用共享文件系统方法来获取工件，但在我们目前正在做的工作范围内，使用存储库管理器将获得什么，我们还有一些问题。我们确实使用TeamCity作为构建服务器，它正在部署到当前使用的文件系统中。在对回购经理进行POC操作之前，我需要知道一些问题的答案。
install是本地存储库特有的。
从Maven的角度来看，远程存储库是由存储库管理器托管还是完全外部存储库都没有相关性——当您将工件添加到任何类型的远程存储库时，您需要使用deploy插件(或release用于非琐碎的部署)。
存储库管理器通常会生成有关配置项目以部署到托管回购的说明。
maven定义了一个生命周期(清理、编译、安装、部署…)。执行"mvn-install"时有默认映射。所以maven知道要执行哪些插件来实现maven的目标。
简介页面很好地概述了每个阶段(目标)的情况以及默认插件是什么：https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
在您的情况下：mvn-install会将工件复制到本地maven存储库中，以便由本地的其他项目共享。
如果您想与其他位置的其他开发人员共享工件，"mvn-deploy"会将工件复制到远程存储库。请注意，您需要在pom.xml中配置distributionManagement部分才能做到这一点。
正常的maven设置应该如下所示：
项目->本地存储库->私有远程存储库->公共远程存储库
项目：在最简单的情况下，您的项目由源文件和配置文件(pom.xml)组成。该项目可能依赖于第三方库，如junit。库的jar文件不存储在项目目录中，只存储需要哪些jar的信息。
mvn package
此命令从项目中创建一个jar，并将其放置在项目的target/文件夹中。
本地存储库：这是一个本地存储在您的机器上的maven存储库。它通常驻留在~/.m2/repository/中。您在项目中使用的每个依赖项都将存储在此存储库中。在编译项目时，maven将使用这个位置的jar文件。
mvn install
此命令创建一个jar文件并将其复制到本地存储库：~/.m2/repository/groupId/artifactId/version/project.jar。现在，您可以在不同的独立项目中使用这个jar作为依赖项，但只能使用您的机器。
专用远程存储库：大多数情况下，这是您公司网络中的Nexus。此服务器允许在开发人员之间共享构建项目。TeamCity服务器构建jar并将其复制到nexus服务器。除此之外，nexus服务器的工作方式类似于代理，例如，开发人员需要junit4.1.1.jar，因此服务器在公共远程存储库中查找并缓存它。
mvn deploy
该命令构建一个jar并将其发送到您的nexus服务器("到您的私人远程存储库")。之后，公司网络中的每个开发人员都可以访问该jar。
公共远程存储库：这些存储库在互联网上可用，其中包含几个jar文件，例如maven.codehaus.org
摘要：
如果调用mvn compile，maven将在本地存储库中查找依赖项。如果maven找不到它们，它会询问(私有/公共)远程存储库，并将文件复制到本地存储库。
您不应该通过网络同步本地存储库，因为这种类型的存储库不是针对这种用途的，并且可能会以某种模糊的方式中断。
您需要的是一个mvn deploy-将最终包复制到远程存储库，以便与其他开发人员和项目共享
您尝试的mvn install只会在本地~/.m2存储库中构建并安装项目。它不会将工件发布到您配置的nexus存储库中。
安装和部署都是有效的构建阶段，这意味着它执行之前的所有阶段。请参阅下面的Maven文档以了解更多信息。
来自maven文档：
默认的Maven生命周期有以下构建阶段(有关构建阶段的完整列表，请参阅生命周期参考)：
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
**install** - install the package into the local repository, for use as a dependency in other projects locally
**deploy** - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.