2014-02-26 40 views
1

我对我们的项目使用存储库管理器缺乏一些基本的了解。我不知道的是,如果我使用存储库管理器,如何运行本地install命令,Maven不会将该包部署到像共享Nexus实例那样的东西。在使用存储库管理器时,我似乎在本地存储库和共享存储库之间存在一些混淆。Maven在使用存储库管理器时安装本地使用

道歉为naivity和不测试这个我自己。我们已经开始对我们的应用程序进行版本控制,并使用共享文件系统方法来获取构件,并且留下一些关于在我们目前的工作范围内,通过使用库管理器来获得什么的问题。我们确实使用TeamCity作为构建服务器来部署到当前使用的文件系统。在购买回购经理之前,我需要知道一些问题的答案。

回答

2

installspecific to the local repository

从Maven的角度来看远程仓库是否是由您的存储库管理托管或完全外部没有相关性 - 当你加入你的神器任何种类的远程仓库,你需要使用deploy plugin(或用于非平凡部署的release)。

存储库管理器通常会生成有关配置项目以部署到托管存储库的说明。

1

maven定义了一个生命周期(clean,compile,install,deploy ...)。执行“mvn install”时有默认映射。所以maven知道哪些插件可以执行该maven目标。

的介绍页面给出了一个很好的概述,对每个阶段(目标)会发生什么,什么默认插件是:https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

你的情况:MVN安装将工件复制到本地Maven仓库被共享您在当地的其他项目。

如果您想与其他位置的其他开发人员共享工件,“mvn deploy”会将工件复制到远程存储库。请注意,您需要在pom.xml中配置distributionManagement部分才能做到这一点。

1

正常Maven的设置应该是这样的:

项目 - >本地资源库 - >私有远程仓库 - >公共远程仓库

项目:在最简单的情况下,你的项目包括源文件和一个配置文件(pom.xml)。该项目可能依赖于像junit这样的第三方库。库的jar文件不存储在项目目录中,只存储需要的信息。

mvn package 

此命令创建一个罐子您的项目的地方在您的项目的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 

此命令建立一个罐子,它的每一个开发人员发送到您的Nexus服务器(“您的私人远程仓库”)后,您的公司网络内部可以访问罐子。

公共远程存储库:这些是互联网上可用的存储库,其中包含多个jar文件,例如, maven.codehaus.org

摘要

如果你打电话mvn compile行家会在你的本地库的依赖关系。如果maven找不到它们,它会询问(private/public)远程仓库,并将这些文件复制到本地仓库。

您不应该通过网络同步本地存储库,因为此类存储库不针对此类使用,并且可能会以某种模糊的方式破解。

1

你需要的是一个mvn deploy - 复制最终的包到远程仓库与其他开发者共享和项目

mvn install你试图将刚刚建立并在当地〜/ .m2目录库安装工程。它不会将工件发布到您已配置的连接库。

安装和部署都是有效的构建阶段 - 意味着它执行以前的所有阶段。请参阅下面的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.