1. Overview

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

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 quickly becomes the only real and mature option for hosting third party artifacts, as well as for reusing internal artifacts across development streams.

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

2. Nexus requirements in the pom

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:

<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.

3. The plugins

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

<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.

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. 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.

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.

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.

4. The Global 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.

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.

The credentials of the server has to be defined in the global 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 convigured to use key based security instead of raw and plaintext credentials.

5. The deployment process

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.

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

mvn clean deploy

6. Conclusion

This is a simple, yet highly effective solution to deploying to Maven artifacts to 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.

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.

Get the early-bird price (20% Off) of my upcoming "Learn Spring Security" Course:

>> CHECK OUT THE COURSE

  • TonyYPZhang

    thanks

  • Alon

    Is it possible to to write pom.xml without mentioning

    nexus-snapshots
    http://localhost:8081/nexus/content/repositories/snapshots

    For instance if we move nexus server, i don’t want to change 200 POMs to point to the new server, i prefer to update settings.xml or stuff like that.

    • Hey Alon – that’s an interesting question and definitely a valid usecase. However, I haven’t tried to see if it works before, so I’m not sure. I’d suggest having a look at the settings.xml documented syntax to see if it supports the element (which I think it should). And then, with a working example, make the switch and see if it works or not.
      Hope that helps. Cheers,
      Eugen.

      • Alon

        Hi Eugen,

        The workaround or may be a solution that I currently found is following:

        In pom.xml I put code:

        releases
        Releases Repository
        ${repo.url}

        In settings.xml I added this configuration:

        repositories

        my host name

        repositories

        releases
        admin
        admin123

        • Sounds good. Does that mean that moving the entire element to settings.xml wasn’t an option?

          • Alon

            Which element you are talking about?

          • I was thinking that you might be able to move – but that’s project specific, so it makes sense to have it in the pom.