0% found this document useful (0 votes)
273 views10 pages

Publish Artifacts To Nexus

The document discusses publishing artifacts to a Nexus repository. The main purposes of an artifact repository are to store dependencies that cannot be freely downloaded, and to have a central place to store and manage releases. Maven projects can be configured to deploy artifacts to Nexus by adding distribution management and plugin configuration to the pom.xml file. Jenkins jobs can also be set up with Maven and Nexus plugins to automatically deploy build artifacts to Nexus.

Uploaded by

Rabbani Shaikh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
273 views10 pages

Publish Artifacts To Nexus

The document discusses publishing artifacts to a Nexus repository. The main purposes of an artifact repository are to store dependencies that cannot be freely downloaded, and to have a central place to store and manage releases. Maven projects can be configured to deploy artifacts to Nexus by adding distribution management and plugin configuration to the pom.xml file. Jenkins jobs can also be set up with Maven and Nexus plugins to automatically deploy build artifacts to Nexus.

Uploaded by

Rabbani Shaikh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Publish Artifacts to Nexus

An artifact repository has several purposes. The main purpose is to have a copy of maven central (or any
other maven repo) to have faster download times and you can use maven even if the internet is down. Since
you are not using maven this is irrelevant for you.

The second purpose is to store files in it you want to use as dependency but you cannot download freely
from the internet. So you buy them or get them from your vendors and put them in your repo. This is also
more applicable to maven user and there dependency mechanism.

The third important purpose is to have a central way were you can store your releases. So if you build a
release v1.0 you can upload it to such a repository and with the clean way of naming in maven its kind a
easy to know how to find v1.0 and to use it with all other tools. So you could write a script which
downloads your release with wget and install it on a host.

Most of the time these repos have a way of a staging process. So you can store v1.0 in the repo in staging.
Someone do the test and when its fine he promotes it to the release repo were everybody can find and use it.

Its simple to integrate them with Maven projects and they are lot of other build tools frameworks with has a
easy possibility to connect against it like ant ivy, groovy grape and so on. Because of the naming schema
there is no limitation that you use bash or perl to download/upload files from it.
Add the dependencies and plugins
Nexus Requirements in the pom.xml

In Maven to be able to deploy the artifacts (jar/war) 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 distribution
Management 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.
Add maven-deploy-plugin in the pom.xml, the deploy goal of the plugin is mapped to the deploy phase of
the Maven build, default Maven lifecycle. The maven-deploy-plugin is deploying to artifacts of a project to
Nexus. In the build tag create the below plugins in pom.xml

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

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 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 Nexus repo and credentials of this deployment user, so
that it can interact correctly with Nexus. The credentials of the server have to be defined in the global
Maven in linux" conf/setting.xml" in windows "~/.m2/settings.xml".

<servers>
<server>
<id>OUR REPOSTORY/SNAPSHOT NAME</id>
<username>OUR NEXUS USERNAME</username>
<password>OUR NEXUS PASSWORD</password>
</server>
</servers>

Publishing Artifacts Using Maven Job


Below example to pushing jar/war to nexus repository by doing manually and using plugins. Now you can
create a job with the ‘Maven project’ In the Jenkins dashboard, click the New Item option.

Go to Jenkins Dashboard -> New Item -> Maven Project option will be available-> Choose name for the
Maven Project (e.g. maven nexus project). Enter an item name and click on OK
After job creation we will get the Job setup UI in that select the source code management (i.e., SVN, Git or
Bitbucket) give the your project url. Here am selecting git, and clone your project from your github and
paste the url from Repository url and select the branch.

Then go to Build and set the path of your Pom.xml and type the Goals of your maven project (like clean
install deploy) and save the job.
After Configuration the job select the build now, job will trigged according to our configuration our artifact
will upload the Nexus. once check the logs if jar/war uploaded or not, select the job and we will get the
option and select or open the console output. If build will success you will get 'Blue' color if build fails get
'red' color if your want changes/modify in job select the configure and modify the job.
If you want see the output or logs of the job select the job and we will get the option and select or open the
console output, scroll down you will get the build success

In console output we see the build success and uploading artifacts:


PUBLISHING ARTIFACTS USING NEXUS ARTIFACT UPLOADER PLUGIN
Before configuration the job, firstly we can download the nexus artifact uploader plugin Go to Jenkins Dashboard -
>Manage Jenkins ->Manage plugins ->Available ->NEXUS ARTIFACTUPLOADER ->Install Without
restart

After completing the source code management (configuring git url and branch) we can click the post
steps we select the nexus Artifact Uploader. In this plugin we are used it allows to use the configuration of
Nexus with versions of Nexus 3 and Nexus 2 along with HTTPS and HTPP protocols. Nexus. So let's
compose some of the parameters:

Nexus Version: It can be nexus3 or nexus2.


Protocol: It can be https or http.
Nexus Url: For this example is the address where you have located you Nexus OSS instance without
including the protocol "http" nor "https." For this example we use 192.168.1.16:8081
repository: The name of the repository, in nexus.
Credentials Id: This is the ID of the credential stored in Jenkins. Try to specify a mnemonic id in Jenkins
otherwise this will be auto generated in Jenkins assigning it a random hash value.
Artifacts: This is very important. A lot of examples I reviewed only upload the binary artifact but it's so
critical to upload our pom.xml file as type "pom." This is important to allow transitive dependencies in case
our artifacts contains more information, just as another project referencing it might need some "extra"
information to figure out how or what dependencies to include, a lot of your builds might be just fine even
without uploading this. It could compile or package them fine but you might face hard to track Runtime
Exceptions due to a lack of dependencies. You could face issues with this kind of message in you maven log
builds

**[WARNING] The POM for groupId:artifactId:version is missing, no dependency information


available**

So in order to avoid the above messages we always should upload our pom.xml to Nexus, so for that the
parameter it accepts an array of artifacts. This Job has the particularity helping us defining these variables
which are quite self-explained with the information extracted from the pom.xml file:

${POM_VERSION}
${POM_GROUPID}
${POM_ARTIFACTID}
${POM_PACKAGING}

Notice we are dynamically building the artifact name using the expression, but you know this can vary if
you set a custom artifact name in the pom.xml.

target/${POM_ARTIFACTID}-${POM_VERSION}.${POM_PACKAGING} ,
screenshots:
On Nexus repository we see the jar/war

You might also like