Infrastructure with maven, Jenkins, Nexus

Question

We are using maven. I want to set up infrastructure, so that automatically built artifacts would go to Nexus repository. And then they could be used by developers.

I have already set up Jenkins with 1 job for our project. And I set up Nexus to on the same server.

On developers' PCs I copied default maven setting to C:\Users{user}.m2\settings.xml adding this section. References:

Configuring Maven to Use a Single Nexus

Maven Settings Reference

<mirror>
  <!--This sends everything else to /public -->
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://myserver:8081/nexus/content/groups/public</url>
</mirror>

(I just follow Repository Management with Nexus book)

What are my next steps should be? Should Jenkins job have mvn install? How to create Nexus repository for company artifacts?

Solution 1

To deploy artifacts to Nexus, you'll need to include a distributionManagement section in your pom. Nexus ships with specific repositories already set up for both snapshots and releases. You should give the correct path to each of those so that maven will deploy snapshot and release artifacts to the correct repos. Then any time you deploy artifacts--typically with mvn deploy or using the maven release plugin, the artifacts will be deployed there. Nexus has write authentication on by default, so you'll need to make sure to add a server section with the correct credentials to the settings.xml of anyone who will be deploying artifacts. Jenkins can be treated pretty much like any other user. If you have it do a deploy as its build, then every build will deploy to Nexus. There's also a post-build action for deploying artifacts in case you want it to happen later in the Jenkins job.

Solution 2

I didn't need to make any changes to my projects pom.xml. Instead, in the jenkins "Post-build Actions" I selected "Deploy artifacts to Maven repository" then selected "Advanced" and set the Repository URL to http://nexusserver:8081/nexus/content/repositories/releases and the Repository ID to deploymentRepo.

In the ~/.m2/settings.xml on the jenkins machine I added

<settings>
  <servers>
    <server>
      <id>deploymentRepo</id>
      <username>deployment</username>
      <password>deployment123</password>
    </server>
  </servers>
   ...

</settings>

Solution 3

update pom.xml

 <distributionManagement>
    ...
    <repository>
      <id>deploymentRepo</id>
      <name>Internal Releases</name>
      <url>http://nexusserver:8081/nexus/content/repositories/releases</url>
    </repository>
    ...
  </distributionManagement>

then for maven ~/.m2/settings.xml add (this is default deployment user in Nexus)

<server>
  <id>deploymentRepo</id>
  <username>deployment</username>
  <password>deployment123</password>
 </server>

then mvn deploy

Then it is possible to use deployed artifact in any project, just as standard artifacts. In this case add to pom.xml

<!-- company repositories -->
    <repository>
        <id>deploymentRepoReleases</id>
        <name>Releases (Nexus)</name>
        <url>http://nexusserver:8081/nexus/content/repositories/releases/</url>
    </repository>
    <repository>
        <id>deploymentRepoSnapshots</id>
        <name>Snapshots (Nexus)</name>
        <url>http://nexusserver:8081/nexus/content/repositories/snapshots/</url>
    </repository>

UPDATE: Later we went away from Snapshot repositories and were using maven-release-plugin that only needs repositories of release type.

Solution 4

Following maven goal arguments for the maven-release-plugin can be used to pass the nexus repository authentication

-Dusername=<> -Dpassword=<>

use with jenkins project, maven command line, for nexus repo authentication

Solution 5

If this is a Jenkins question rather than a Maven question, I'd recommend using the inbuilt Jenkins "Deploy Artifacts to Maven repository" Post build Action for most cases.

Advantages in my opinion:

• More portable (we use different repositories for different stages of the life cycle), and each Jenkins instance knows it's own repository
• More obvious to anyone reading the Jenkins job
• More in line with the Jenkins way of doing things

View more solutions