我对我们的项目使用存储库管理器缺乏一些基本的了解。我不知道的是,如果我使用存储库管理器,如果我运行本地install
命令,Maven不会将程序包部署到类似共享的Nexus实例。在使用存储库管理器时,我似乎在本地存储库和共享存储库之间存在一些混淆。
为自己的天真和不自己测试而道歉。我们已经开始对应用程序进行版本控制并使用共享文件系统方法来获取工件,并且在使用存储库管理器的情况下,在我们当前正在进行的工作范围内留下一些问题。我们使用TeamCity作为构建服务器,该服务器正在部署到当前使用的文件系统。在POCing回购经理之前,我需要先了解一些问题的答案。
答案 0 :(得分:2)
install
是specific to the local repository。
从Maven的角度来看,远程存储库是由存储库管理器托管还是完全是外部存储器没有相关性 - 当您将工件添加到任何类型的远程存储库时,您需要使用{{ 3}} (或deploy
plugin用于非平凡部署)。
存储库管理员通常会生成有关配置项目以部署到托管仓库的说明。
答案 1 :(得分:1)
maven定义了一个生命周期(清理,编译,安装,部署......)。执行“mvn install”时有默认映射。所以maven知道要为该maven目标执行哪些插件。
“简介”页面概述了每个阶段(目标)发生的情况以及默认插件的内容:https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
在您的情况下:mvn install会将工件复制到本地maven存储库中,以供本地其他项目共享。
如果要与其他位置的其他开发人员共享工件,“mvn deploy”会将工件复制到远程存储库。请注意,您需要在pom.xml中配置distributionManagement部分才能执行此操作。
答案 2 :(得分:1)
正常的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服务器就像代理一样工作,例如开发人员需要junit-4.1.1.jar,因此服务器在公共远程存储库中查找并缓存它。
mvn deploy
此命令构建一个jar并将其发送到您的nexus服务器('到您的私有远程存储库')之后,公司网络中的每个开发人员都可以访问该jar。
公共远程存储库:这些是Internet上可用的存储库,其中包含多个jar文件,例如: maven.codehaus.org
<强>摘要强>:
如果您致电mvn compile
,maven将在您的本地存储库中查找依赖项。如果maven找不到它们,它将询问(私有/公共)远程存储库,并将文件复制到本地存储库。
您不应该通过网络同步本地存储库,因为这种类型的存储库不是以此类用途为目标,并且可能以某种模糊的方式中断。
答案 3 :(得分:1)
您需要的是mvn deploy
- 将最终包复制到远程存储库以与其他开发人员和项目共享
mvn install
只是在你的本地〜/ .m2存储库中构建和安装项目。它将不会将工件发布到您已配置的nexus存储库。
安装和部署都是有效的构建阶段 - 这意味着它将执行所有先前的阶段。请参阅下面的Maven文档以获得更多理解。
来自maven documentation:
默认的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.