Maven Deploy to Nexus – Maven部署到Nexus

1. Overview

1.概述

In a previous article, I discussed how a Maven project can install locally a third party jar that has not yet been deployed on Maven Central (or on any of the other large and publicly hosted repositories).

在上一篇文章中，我讨论了Maven项目如何在本地安装尚未部署在Maven Central（或其他大型公开托管仓库）的第三方jar。

That solution should only be applied in small projects where installing, running and maintaining a full Nexus server may be overkill. However, as a project grows,

这种解决方案只应适用于小型项目，因为在这些项目中，安装、运行和维护一个完整的Nexus服务器可能是多余的。然而，随着项目的发展。

Nexus quickly becomes the only real and mature option for hosting third party artifacts, as well as for reusing internal artifacts across development streams.

Nexus很快成为唯一真正成熟的选择，用于托管第三方工件，以及跨开发流重复使用内部工件。

This article will show how to deploy the artifacts of a project to Nexus, with Maven.

本文将介绍如何用Maven将项目的工件部署到Nexus。

2. Nexus Requirements in the pom.xml

2、pom.xml中的Nexus要求

In order for Maven to be able to deploy the artifacts it creates in the package phase of the build, it needs to define the repository information where the packaged artifacts will be deployed, via the distributionManagement element:

为了让Maven能够部署它在构建的打包阶段创建的工件，它需要通过distributionManagement元素定义打包工件的仓库信息：
。

<distributionManagement>
   <snapshotRepository>
      <id>nexus-snapshots</id>
      <url>http://localhost:8081/nexus/content/repositories/snapshots</url>
   </snapshotRepository>
</distributionManagement>

A hosted, public Snapshots repository comes out of the box on Nexus, so there’s no need to create or configure anything further. Nexus makes it easy to determine the URLs of its hosted repositories – each repository displays the exact entry to be added in the <distributionManagement> of the project pom, under the Summary tab.

在Nexus上，托管的公共Snapshots资源库开箱即用，所以不需要再创建或配置什么。Nexus很容易确定其托管资源库的URL–每个资源库都会在项目pom的<distributionManagement>中的Summary标签下显示要添加的确切条目。

3. Plugins

3.插件

By default, Maven handles the deployment mechanism via the maven-deploy-plugin – this mapped to the deployment phase of the default Maven lifecycle:

默认情况下，Maven通过maven-deploy-plugin处理部署机制–这与默认Maven生命周期中的deployment阶段相吻合。

<plugin>
   <artifactId>maven-deploy-plugin</artifactId>
   <version>2.8.1</version>
   <executions>
      <execution>
         <id>default-deploy</id>
         <phase>deploy</phase>
         <goals>
            <goal>deploy</goal>
         </goals>
      </execution>
   </executions>
</plugin>

The maven-deploy-plugin is a viable option to handle the task of deploying to artifacts of a project to Nexus, but it was not built to take full advantage of what Nexus has to offer. Because of that fact, Sonatype built a Nexus specific plugin – the nexus-staging-maven-plugin – that is actually designed to take full advantage of the more advanced functionality that Nexus has to offer – functionality such as staging.

maven-deploy-plugin是处理向Nexus部署项目工件任务的一个可行选择，但它并不是为了充分利用Nexus所提供的功能。正因为如此，Sonatype建立了一个Nexus专用插件–nexus-staging-maven-plugin，它实际上是为了充分利用Nexus所提供的更高级的功能–如staging功能。

Although for a simple deployment process we do not require staging functionality, we will go forward with this custom Nexus plugin since it was built with the clear purpose to talk to Nexus well.

虽然对于一个简单的部署过程，我们不需要暂存功能，但我们将继续使用这个定制的Nexus插件，因为它的目的很明确，就是要与Nexus很好地对话。

The only reason to use the maven-deploy-plugin is to keep open the option of using an alternative to Nexus in the future – for example, an Artifactory repository. However, unlike other components that may actually change throughout the lifecycle of a project, the Maven Repository Manager is highly unlikely to change, so that flexibility is not required.

使用maven-deploy-plugin的唯一原因是为将来使用Nexus的替代方案留有余地，例如，Artifactory资源库。然而，与其他可能在项目生命周期中实际改变的组件不同，Maven仓库管理器极不可能改变，所以不需要这种灵活性。

So, the first step in using another deployment plugin in the deploy phase is to disable the existing, default mapping:

因此，在部署阶段使用另一个部署插件的第一步是禁用现有的、默认的映射。

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-deploy-plugin</artifactId>
   <version>${maven-deploy-plugin.version}</version>
   <configuration>
      <skip>true</skip>
   </configuration>
</plugin>

Now, we can define:

现在，我们可以定义。

<plugin>
   <groupId>org.sonatype.plugins</groupId>
   <artifactId>nexus-staging-maven-plugin</artifactId>
   <version>1.5.1</version>
   <executions>
      <execution>
         <id>default-deploy</id>
         <phase>deploy</phase>
         <goals>
            <goal>deploy</goal>
         </goals>
      </execution>
   </executions>
   <configuration>
      <serverId>nexus</serverId>
      <nexusUrl>http://localhost:8081/nexus/</nexusUrl>
      <skipStaging>true</skipStaging>
   </configuration>
</plugin>

The deploy goal of the plugin is mapped to the deploy phase of the Maven build.

该插件的deploy目标被映射到Maven构建的deploy阶段。

Also notice that, as discussed, we do not need staging functionality in a simple deployment of -SNAPSHOT artifacts to Nexus, so that is fully disabled via the <skipStaging> element.

还要注意的是，正如所讨论的，在简单部署-SNAPSHOT工件到Nexus时，我们不需要暂存功能，所以通过<skipStaging>元素完全禁用。

By default, the deploy goal includes the staging workflow, which is recommended for release builds.

默认情况下，部署目标包括暂存工作流程，建议用于发布构建。

4. The Global settings.xml

4.全局的settings.xml

Deployment to Nexus is a secured operation – and a deployment user exists for this purpose out of the box on any Nexus instance.

部署到Nexus是一个安全的操作–在任何Nexus实例上都有一个deployment用户为这个目的开箱即用。

Configuring Maven with the credentials of this deployment user, so that it can interact correctly with Nexus, cannot be done in the pom.xml of the project. This is because the syntax of the pom doesn’t allow it, not to mention the fact that the pom may be a public artifact, so not well suited to hold credential information.

在项目的pom.xml中不能用该部署用户的凭证配置Maven，以便它能与Nexus正确互动。这是因为pom的语法不允许这样做，更何况pom可能是一个公共工件，所以不适合保存凭据信息。

The credentials of the server have to be defined in the global Maven setting.xml:

服务器的凭证必须在全局Maven setting.xml中定义。

<servers>
   <server>
      <id>nexus-snapshots</id>
      <username>deployment</username>
      <password>the_pass_for_the_deployment_user</password>
   </server>
</servers>

The server can also be configured to use key based security instead of raw and plaintext credentials.

服务器也可以被配置为使用基于密钥的安全，而不是原始和明文凭证。

5. The Deployment Process

5.部署过程

Performing the deployment process is a simple task:

执行部署过程是一项简单的任务。

mvn clean deploy -Dmaven.test.skip=true

Skipping tests is OK in the context of a deployment job because this job should be the last job from a deployment pipeline for the project.

在部署工作的背景下，跳过测试是可以的，因为这个工作应该是项目的部署管道的最后一个工作。

A common example of such a deployment pipeline would be a succession of Jenkins jobs, each triggering the next only if it completes successfully. As such, it is the responsibility of the previous jobs in the pipeline to run all tests suites from the project – by the time the deployment job runs, all tests should already pass.

这种部署管道的一个常见例子是连续的Jenkins作业，每个作业只有在成功完成后才会触发下一个作业。因此，管道中的前几个作业有责任运行项目中的所有测试套件–在部署作业运行时，所有测试都应该通过。

If ran a single command, then tests can be kept active to run before the deployment phase executes:

如果运行一条命令，那么在deployment阶段执行之前，测试可以保持激活运行。

mvn clean deploy

6. Conclusion

6.结论

This is a simple, yet highly effective solution to deploying to Maven artifacts to Nexus.

这是一个简单而又高效的解决方案，可以将Maven工件部署到Nexus上。

It is also somewhat opinionated – nexus-staging-maven-plugin is used instead of the default maven-deploy-plugin; staging functionality is disabled, etc – it is these choices that make the solution simple and practical.

它也有些见仁见智–使用nexus-staging-maven-plugin而不是默认的maven-deploy-plugin；禁用staging功能等等–正是这些选择使解决方案简单实用。

Potentially activating the full staging functionality can be the subject of a future article.

潜在的激活完整的分期功能可以成为未来文章的主题。

Finally, we’ll discuss the Release Process in the next article.

最后，我们将在下一篇文章中讨论发布过程。