Skip to content


Subversion checkout URL

You can clone with
Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

1364 lines (1054 sloc) 48.706 kB

Prerequisites and Preparation

The following guide for evaluating Sonatype Nexus is based on an assumption of installing Nexus itself as well as the various technologies used in the specific evaluation example all on one computer. A more extended evaluation of Nexus in a team environment should follow the instructions for a full installation as documented in the book Repository Management with Nexus. Consult the book for further in-depth documentation about all features of Nexus.

Besides the installation of Nexus itself, various evaluations will need different prerequisites installed on the machine you use for your evaluation. The installation instructions of these technologies follow below. Only follow the instructions referenced from the examples in which you are interested. For example you will only need to install Visual Studio and NuGet if you want to evaluate the .Net Integration of Nexus.

A Note about the Operating System

Some of the tasks described are referencing command line calls. Where that is the case, this guide will use Unix typical commands and syntax as used on a bash shell. This is the most common environment on Linux and Mac OSX computers. On Windows machines, a bash shell can be installed as well, using the cygwin system. However the typical usage would be to use the Windows command prompt with slightly different calls. Commandline Invocation Examples displays a number of examples for typical tasks carried out in the evaluations with their bash as well as Windows shell commands.

Table 1. Commandline Invocation Examples
Task Bash Shell Window Shell

Delete a file

rm filename

del filename

Delete a directory

rm -rf directoryname

rmdir directoryname

Delete a directory in users home directory

rm -rf ~/.m2/repository

rmdir /S %HOMEPATH%\.m2\repository

Change to the users home directory

cd ~


Script invocation



Gradle Wrapper script invocation



Java Runtime

Nexus itself as well as some of the technologies used in the evaluation require a Java runtime or development kit, which is available for most operating systems. We recommend to install the latest Oracle Java 7 JDK available from the download web page and following the installation instructions on the same site.

After a successful installation, you can verify it by running the command java -version, which should result in an output similar to

java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
Nexus requires Java 7 or Java 8.

Apache Maven

Apache Maven can be retrieved from the download page and installed following the instructions available there. We recommend the usage of the latest available Maven 3 version.

After a successful installation you can verify it with running the command mvn --version, which should result in an output similar to

Apache Maven 3.3.3 (799...; 2015-04-22T04:57:37-07:00)
Maven home: /opt/tools/apache-maven-3.3.3
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"


The examples in this guide use the so-called Gradle wrapper script. It allows you to get Gradle installed automatically by the wrapper and invoke all Gradle commands via it. To use it you simple invoke all gradle commands with ./gradlew on Unix based systems and gradlew.bat on Windows instead of gradle.

Alternatively Gradle can be retrieved from the download page and installed following the instructions available in the User Guide. We recommend the usage of the latest available Gradle version.

After a successful installation, you can verify it with running the command gradle -v, which should result in an output similar to

Gradle 2.0

Build time:   2014-07-01 07:45:34 UTC
Build number: none
Revision:     b6ead6fa452dfdadec484059191eb641d817226c

Groovy:       2.3.3
Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM:          1.7.0_65 (Oracle Corporation 24.65-b04)
OS:           Mac OS X 10.8.5 x86_64

Apache Ant and Apache Ivy

Apache Ant can be retrieved from the download page and installed following the instructions available in the manual. We recommend the usage of the latest available Ant version.

After a successful completion,f you can verify your Ant installation by running the command ant -version, which should result in an output similar to

Apache Ant(TM) version 1.9.4 compiled on April 29 2014

The example projects used in this guide contain ant targets in their build files that will automatically install Apache Ivy as part of the build. Alternatively you can retrieve Apache Ivy from the download page and install it following the instructions.

Microsoft Visual Studio and NuGet

Microsoft Visual Studio and NuGet are needed to evaluate the .Net support of Nexus Pro. There are a number of different Visual Studio distributions. Some of these distributions may have NuGet already installed, while others do not. Even if your Visual Studio installation is bundled with NuGet, you will want to make sure that you have upgraded to the latest version of the tool.

NuGet is a fast-paced project, and you’ll find that new packages available on NuGet Gallery may not be compatible with older versions of the NuGet package manager.

For detailed instructions on installing NuGet in Visual Studio, please go to the NuGet project’s documentation site and refer to the Installing NuGet instructions.

Getting Started

This guide is based on the usage of Nexus Pro. A lot of the core features are available in Nexus OSS as well and some examples are suitable to assess the open source version as well.

When Nexus has started just click the URL in the wizard or go to http://localhost:8081/nexus in a browser window.

This guide and the examples reference the Nexus URL http://localhost:8081/nexus. If you have chosen to use a different port during the installation of the trial simply change the URLs.

Below are are several directories to know:

Nexus Installation Directory: This is where the Nexus application files are installed on your system. We refer to this as <nexus_install>.

Nexus Work Directory: This directory contains your specific Nexus instance configuration files. We refer to this as <nexus_work>.

Nexus Eval Guide Directory: This directory contains supporting sample project files and this document. We refer to this as <nexus_eval>.

You can locate these directories by viewing the Nexus Control Panel.

In case something goes wrong and Nexus seems to be unavailable, you can examine the following two log files to diagnose problems.


Nexus tries to listen on port 8081. If you have another application listening on this port, Nexus will not be able to start. You can change the port Nexus listens on. Open this file


Edit the line that looks like this:


For example, to access Nexus on port 9090 instead, change the line to


Save the file and restart Nexus.

Activating Your Nexus Trial

Once Nexus is started and you are accessing the user interface the first time, you will see the trial activation form. Provide your full name, email address, organization, and location and click on Submit Activation Request.

You will immediately receive an email from Sonatype with the subject “Your Nexus Pro Trial License,” which contains your trial license key. Paste this license key into the license field in the Nexus Pro user interface. Click Activate to activate your 14-day Nexus Pro trial. Once your trial is activated, you will be presented with the Nexus user interface.

Logging Into Nexus as an Administrator

After activating your Nexus install, you can log into Nexus as an administrator. Go to http://localhost:8081/nexus/ and click on the Login button in the upper right-hand corner of the interface.

eval login
Figure 1. Nexus User Interface with Login

The default administrator username is admin and password is admin123.

The Nexus Pro Trial evaluation guide assumes that you are logged in as an administrator.

Getting Started with Your Nexus Pro Evaluation

To make it easier to evaluate Nexus, we’ve created a set of projects to demonstrate the features of Nexus OSS and Nexus Pro. These example projects are bundled with the trial installer for your convenience.

In addition, they are available as the nexus-book-examples project on GitHub at for you to download and inspect separately, if desired. The latest version of all the examples is available as a zip archive at

When you downloaded the trial distribution of Nexus Pro, your server is also preconfigured to demonstrate important features.

The Nexus trial distribution contains the following customizations:

  • Nexus has been preconfigured to download the search index from the Central Repository.

  • A Staging profile has been configured to demonstrate release management.

  • Nexus proxies NuGet Gallery so that you can quickly evaluate support for .NET development.

The Basics: Proxying and Publishing

After a few weeks the importance of having a repository manager is so obvious no one on my team can believe we used to develop software without one.

Financial Industry
— Build Engineer

If you are new to repository management, the first step is to evaluate the two basic benefits of running a repository manager: proxying and publishing.

You can reap these benefits with any Java/JVM build system that includes declarative dependency management and understands the Maven repository format. In the following we are going to cover the details for Apache Maven, Gradle and Apache Ant/Apache Ivy based builds. Build tools like SBT, Leiningen, Gant/Grails and others can be configured to do the same and get access to the same benefits.

Proxying Components

If you use a dependency in your software, your build downloads components from a remote repository, such as the Central Repository and others. Your systems depend on these components. If one of these critical remote repositories becomes unavailable, your productivity can grind to a halt.

This is where Nexus can help. Nexus is preconfigured to proxy the Central Repository, and other remote repositories can be easily added. Once set up, Nexus maintains a local cache of the needed components from the remote repositories for you. Your build is more reliable when all the components you require are cached by Nexus. It is providing you with dramatic efficiency and speed improvements across your entire development effort.

In this example, you will…

  • Configure your build to download components from Nexus.

  • Pre-cache dependencies and build components with an initial build.

  • Note organization-wide improvements in build reliability.

Let’s get started using the provided scripts:

The eval bundle includes an installation of Apache Maven as well scripts that isolate your evaluation from the rest of your system and make it extremely easy for you to follow. The Gradle examples use a wrapper script to allow you to simply follow the example. To follow the Ant/Ivy examples you will have to install Apache Ant as explained in Apache Ant and Apache Ivy.

  1. Go to the Nexus evaluation guide directory you configured during the Nexus Pro install, which is named evalguide by default and can be found in your users home directory, and run the command:

    $ cd maven
    $ ./build -f simple-project/pom.xml clean install

    To use Apache Maven or if you want to try Gradle use

    $ cd gradle/simple-project
    $ ./gradlew build

    With Apache Ant and Ivy you can run

    $ cd ant-ivy/simple-project
    $ ant jar
  2. As the project builds, you will notice that all components are downloaded from your local Nexus instance installed with requests from Apache Maven:

    Downloading: http://localhost:8081/nexus/content/groups/public/org
    Downloaded: http://localhost:8081/nexus/content/groups/public/org
      (4 KB at 1.3 KB/sec)

    Here are examples from Gradle:

    Download http://localhost:8081/nexus/content/groups/public/org/
    Download http://localhost:8081/nexus/content/groups/public/org/
    Download http://localhost:8081/nexus/content/groups/public/com/

    Here are examples from Apache Ivy:

    [ivy:retrieve] downloading http://localhost:8081/nexus/content/
      groups/public/asm/asm-commons/3.2/asm-commons-3.2.jar ...
    [ivy:retrieve] .. (32kB)
    [ivy:retrieve] .. (0kB)
    [ivy:retrieve] 	[SUCCESSFUL ] asm#asm-commons;3.2!asm-commons.jar (313ms)
  3. After the build has successfully completed, delete the local Maven repository cache in the eval guide directory and rerun the build as before

    $ cd maven
    $ rm -rf repository

    Delete the Gradle cache with

    $ rm -rf ~/.gradle

    Delete the Ivy cache with

    $ ant clean-cache clean
  4. Notice how the downloads are occurring much faster. The components are no longer retrieved from the remote repositories before being served by Nexus, but they are supplied straight from the proxy repository cache in Nexus.

  5. To verify that components are being cached in Nexus, open the Repositories panel by clicking on Repositories in the left-hand Nexus menu. Once the list of repositories is displayed, select Central. Click on the Browse Storage tab and observe the tree of components downloaded and successfully cached in Nexus.

Alternatively using your own Apache Maven setup:

  1. Ensure that Apache Maven is installed as a prerequisite as documented in Apache Maven.

  2. Go to the Nexus evaluation guide directory you configured during the Nexus Pro install and configure Maven to access Nexus with the provided settings.xml. Ensure to back up any existing settings file and adapt the port in the mirror url, if you have chosen to use a different port than 8081 in the Nexus trial installer.

    $ cp maven/settings/settings.xml ~/.m2/
  3. Optionally, if you do not want to use the default local repository location of Maven in ~/.m2/repository, change the localRepository settings in the settings.xml file to an absolute path.

  4. Build the simple-project, and observe the downloads from the Nexus repository.

    $ cd maven/simple-project/
    $ mvn clean install
  5. After the build has successfully completed, delete the local Maven repository cache and rerun the build. Notice the improved build performance and the cached components in Nexus.

    $ rm -rf ~/.m2/repository

Your builds will be faster and more reliable now that you are caching components in Nexus and retrieving them from there. Once Nexus has cached a component locally, there is no need to make another roundtrip to the remote repository server. The caching benefits all tools configured to access Nexus.

Publishing Components

Nexus makes it easier to share components internally. How do you distribute and deploy your own applications? Without Nexus, internal code is often distributed and deployed using an SCM, a shared file system, or some other inefficient method for sharing binary components.

With Nexus you create hosted repositories, giving you a place to upload your own components to Nexus. You can then feed your components back into the same repositories referenced by all developers in your organization.

In this example, you will…

  • Publish a component to Nexus.

  • Watch another project download this component as a dependency from Nexus.

Let’s get started using the provided scripts:

  1. Follow the proxying evaluation example from Proxying Components.

  2. Go to the Nexus evaluation guide directory and publish the simple-project to Nexus with the Maven wrapper script.

    $ cd maven
    $ ./build -f simple-project/pom.xml clean deploy

    With your own Maven installation you can use

    $ cd maven/simple-project/
    $ mvn clean deploy

    To deploy the project with Gradle, you can run the commands

    $ cd gradle/simple-project
    $ ./gradlew upload

    The equivalent Ant invocation is

    $ cd ant-ivy/simple-project
    $ ant deploy
  3. The simple-project has been preconfigured to publish its build output in the form of a JAR component to your local instance of Nexus Pro.

  4. Observe how the build tools log the deployment to Nexus, e.g., Maven

    Uploading: http://localhost:8081/nexus/content/repositories/snapshots/
    Uploaded: http://localhost:8081/nexus/content/repositories/snapshots/
      simple-project-1.0.0-20130311.231302-1.jar (3 KB at 38.2 KB/sec)


    to repository remote at

    or Ivy

    [ivy:publish] :: publishing ::
    [ivy:publish] 	published simple-project to http://localhost:8081
  5. To verify that the simple-project component was deployed to Nexus, click on Repositories and then select the Snapshots repository. Select the Browse Storage tab as shown in this illustration.

    eval publish
    Figure 2. Successfully Deployed Components in the Snapshots Repository
  6. Once this component has been published, return to the evaluation sample projects directory and run a build of another-project:

    $ cd maven
    $ build -f another-project/pom.xml clean install

    With your own Maven installation you can use

    $ cd maven/another-project
    $ mvn clean install

    To build the second project with Gradle, simply use

    $ cd gradle/another-project
    $ ./gradlew build

    Perform the same action with Ant using

    $ cd ant-ivy/another-project
    $ ant jar
  7. This second project has a dependency on the first project declared in the Maven pom.xml with


    and in the Gradle build.gradle file as

    dependencies {
        compile ""

    Ivy declares the dependency in ivy.xml and it looks like this

      <dependency org="" name="simple-project"

    During the build, it is relying on Nexus when it attempts to retrieve the component from simple-project.

Now that you are sharing components of your projects internally, you do not need to build each other’s software projects anymore. You can focus on writing the code for your own components and the integration of all components to create a larger software component. In fact, it does not even matter which build tool created the component, since the Maven repository format is understood by all of them.


Sonatype Nexus OSS and Pro/Pro+ can serve as an important tool for collaboration between different developers and different development groups. It removes the need to store binaries in source control or shared filesystems and makes collaboration more efficient.


Identify Insecure OSS Components In Nexus

The Repository Health Check in Nexus Pro turns your repository manager into the first line of defence against security vulnerabilities. Nexus Pro scans components and finds cached components with known vulnerabilities from the Common Vulnerabilities and Exposures (CVE) database. You can get an immediate view of your exposure from the Repository Health Check summary report with vulnerabilities grouped by severity according to the Common Vulnerability Scoring System (CVSS).

As your developers download components, they may be unwittingly downloading components with critical security vulnerabilities that might expose your applications to known exploits. According to a joint study by Aspect Security and Sonatype released in 2012, Global 500 corporations downloaded 2.8 million flawed components in one year. Nexus becomes an effective way to discover flawed components in your repositories allowing you to avoid falling victim to known exploits.

eval rhc overview
Figure 3. Repository Heath Check Summary

In this example, you will…

  • Start an analysis of all components proxied from the Central Repository.

  • Inspect the number of security vulnerabilities found.

Let’s get started

  1. Follow the proxying examples in The Basics: Proxying and Publishing to seed the Central proxy repository of your Nexus instance. These examples include several components with security vulnerabilities and license issues as dependencies.

  2. Once your Nexus instance has cached the components, open the Nexus interface, log in as administrator and click on the green Analyze button next to your Central proxy repository.

  3. After the completion of the analysis, the button will change into an indicator of the number of security and license issues found.

  4. Hover your mouse over the indicator and Nexus will show you a summary report detailing the number and type of security vulnerabilities present in you repository.

  5. Optionally, build some of your own applications to get further components proxied and see if additional security issues appear.

eval security
Figure 4. Security Vulnerability Summary Display from Repository Health Check

Nexus Pro users gain access to further details about all the components with security vulnerabilities, including their repository coordinates to uniquely identify the component as well as links to the vulnerability database records for further details.


The Repository Heath Check of Nexus allows you to get an understanding of all the security vulnerabilities affecting the components you have proxied into your environment and which might potentially be part of the software you are creating, distributing, and deploying in production environments.

Track Your Exposure To OSS Licenses

With Open Source Software (OSS) component usage as the de facto standard for enterprise application development, the importance of tracking and identifying your exposure to OSS licenses is an essential part of the software development life cycle. Organizations need tools that let them govern, track, and manage the adoption of open source projects and the evaluation of the licenses and obligations that are part of OSS development and OSS component usage.

With Nexus Pro’s Repository Health Check, your repository becomes more than just a place to store binary components. It becomes a tool to implement policies and govern the open source licenses used in development to create your applications.

In this example, you will…

  • Start an analysis of all components proxied from the Central. Repository

  • Inspect the number of license issues found.

Let’s get started

  1. Follow the proxying examples in The Basics: Proxying and Publishing to seed the Central proxy repository of your Nexus instance. These examples include several components with security vulnerabilities and license issues as dependencies.

  2. Once your Nexus instance has cached the components, log in to the Nexus interface as administrator and click on the green Analyze button next to your Central proxy repository in the Repositories list.

  3. After the completion of the analysis, the button will change into an indicator of the number of security and license issues found.

  4. Hover your mouse over the indicator and Nexus will show you a summary report detailing the number and type of license issues of components present in you repository.

  5. Optionally, build some of your own applications to get further components proxied and see if additional license issues appear.

eval license
Figure 5. License Analysis Summary Display from Repository Health Check

Nexus OSS and the trial version show the summary information found by the analysis.

Nexus Pro customers can access a detailed report to identify specific components with known security vulnerabilities or unacceptable licenses. The component lists can be sorted by OSS license or security vulnerabilities, and Nexus Pro provides specific information about licenses and security vulnerabilities. A detailed walkthrough of this report is available on the Sonatype website.

eval rhc detail
Figure 6. Repository Health Check Details with License Issues List

OSS License compliance and security assessments are not something you do when you have the time. It is something that should be a part of your everyday development cycle, as it is with Nexus Pro’s Repository Health Check.

Process Improvements

Grouping Repositories

Once you have established Nexus and set up your build, provisioning system, and other tools to connect to Nexus, you can take advantage of Nexus repository groups. The best practice to expose Nexus is to get users to connect to the Public Repositories group as configured in the settings.xml as documented in Proxying Components.

When all clients are connecting to Nexus via a group, you can easily provide additional repository content to all users by adding new repositories to the group.

For example, imagine a group in your organization is starting to use components provided by the JBoss release repository available at The developers are already accessing Nexus via the public group. All you have to do is to create a new proxy repository for the JBoss release repository and add it to the public group and all developers, continuous integration (CI) servers and other tools will have access to the additional components.

To add the Grails repositories, proxy them and add them to the group. The same approach applies to proxy Clojars or other repository of a business partner or suppier who is protected by user credentials.

Another advantage of groups is that you can mix release and snapshot repositories and easily expose all the components via one easy access point.

Besides using the default public group, you can create additional groups that expose other contexts. An example would be to create a group for all staged releases allowing a limited number of users access to your release components as part of the release process.


Using groups allows you to expose multiple repositories, mix snapshot and release components and easily administrate it all on the Nexus server. This allows you to provide further components to your developers or other users, without requiring a change on these client system, tremendously simplifying the administration effort.

Staging a Release with Nexus

When was the last time you did a software release to a production system? Did it involve a QA sign-off? What was the process you used to redeploy, if QA found a problem at the last minute? Developers often find themselves limited by the amount of time it takes to respond and create incremental builds during a release.

The Nexus Staging Suite changes this by providing workflow support for binary software components. If you need to create a release component and deploy it to a hosted repository, you can use the Staging Suite to post a release, which can be tested, promoted, or discarded, before it is committed to a release repository.

The following example uses Apache Maven. Example projects for Gradle and Ant are part of the eval guide resources.

In this example, you will…

  • Configure a project to publish its build output component to Nexus.

  • Deploy a release and view the deployed component in a temporary staging repository.

  • Promote or discard the contents of this temporary staging repository.

Let’s get started using the provided scripts:

  1. This example assumes that you have successfully deployed the simple-project as documented in Proxying Components.

  2. Inspect the preconfigured Example Release Profile staging profile by selecting it from the list available after selecting Staging Profiles in the the Build Promotion menu in the left-hand navigation.

  3. Notice that the version of the simple-project in the pom.xml ends with -SNAPSHOT. This means that it is in development.

  4. Change the version of the simple project to release version by removing the -SNAPSHOT in a text editor or run the command

    $ ./build -f simple-project/pom.xml versions:set -DnewVersion=1.0.0
  5. Publish the release to the Nexus Staging suite with

    $ ./build -f simple-project/pom.xml clean deploy
  6. To view the staging repository, click on Staging Repositories in the Build Promotion menu and you should see a single staging repository as shown in this illustration.

  7. Click on Close to close the repository and make it available via the public group.

  8. Experiment with Staging, at this point you can:

    1. Click on Drop to discard the contents of the repository and be able to stage another release.

    2. Click on Release to publish the contents of the repository to the release repository.

  9. Once you release the staging repository, you will be able to find the release components in the Releases hosted repository.

eval staging
Figure 7. Closing a Staging Repository in the Nexus User Interface

The individual transactions triggered by closing, dropping, promoting, or releasing a staging repository can be enriched with email notifications as well as staging rule inspections of the components.

Alternatively using your own Apache Maven setup:

  1. Follow the steps described above with the modification of setting the new version with

    $ cd maven/simple-project
    $ mvn versions:set -DnewVersion=1.0.0
  2. And publishing to the Nexus Staging suite with

    $ mvn clean deploy

Staging gives you a standard interface for controlling and managing releases. A collection of related release components can be staged for qualification and testing as a single atomic unit. These staged release repositories can be discarded or released pending testing and evaluation.

Hosting Project Web Sites

Nexus can be used as a publishing destination for project websites. You don’t have to worry about configuring another web server or configuring your builds to distribute the project site using a different protocol. Simply point your Maven project at Nexus and deploy the project site.

With Nexus as a project’s site hosting solution, there’s no need to ask IT to provision extra web servers just to host project documentation. Keep your development infrastructure consolidated and deploy project sites to the same server that serves your project’s components.

You can use this feature internally, but it is even better suited if you are providing an API or components for integration. You can host full project websites with JavaDoc and any other desired documentation right with the components you provide to your partners and customers.

In this example, you will…

  • Create a Hosted repository with the Maven Site provider.

  • Configure your project to publish a website to Nexus Pro.

Let’s get started using the provided scripts:

  1. Create a hosted repository with the Site format and a Repository ID called siteRead more…

  2. Deploy the simple-project component and site to Nexus:

    $ ./build -f simple-project/pom.xml clean deploy site-deploy
  3. Browse the generate site on Nexus at http://localhost:8081/nexus/content/sites/site/

  4. Optionally, configure your own Maven project to deploy a site to Nexus → Read more…

  5. Publish it to Nexus → Read more…

Alternatively using your own Apache Maven setup:

  1. Follow the steps described above with the modification of deploying the site with

    $ cd maven/simple-project
    $ mvn clean deploy site-deploy

If your projects need to publish HTML reports or a project web site, Nexus provides a consolidated target for publishing project-related content.

Process and Security Improvements with Maven Settings Management and User Token

The Maven settings.xml file plays a key role for retrieving as well as deploying components to Nexus. It contains <server> sections that typically contain the username and password for accessing Nexus in clear text. Especially with single sign-on (SSO) solutions used for Nexus authentication, this is not desirable. In addition, security policies often mean that the file regularly needs to be updated.

The User Token feature of Nexus Pro allows you to replace the SSO username and password with Nexus-specific tokens that are autogenerated and managed by Nexus.

Furthermore, the Nexus Maven Settings Management allows you to manage Maven Settings. Once you have developed a Maven Settings template, developers can connect to Nexus Pro using the Nexus M2Settings Maven plugin that will take responsibility for downloading a Maven Settings file from Nexus and replacing the existing Maven Settings on a local workstation. It can be configured to automatically place your user tokens in the settings.xml file.

In this example, you will…

  • Explore the configuration of a Maven Settings template in Nexus Pro.

  • Activate and access your user token.

Let’s get started

  1. Log into Nexus as administor and access the Maven Settings administration via the item in the Enterprise menu.

  2. Press the Add button, provide a name and edit the new settings file.

  3. Add the server section:

          <!-- User-token: $[userToken] -->
  4. Read more about potential configuration and usage in Manage Maven Settings Templates

  5. Downloading the settings template requires Nexus running via HTTPS and can then be performed with the command below and following the prompts:

    mvn org.sonatype.plugins:nexus-m2settings-maven-plugin:1.6.2:download -Dsecure=false
  6. Note that the secure option is set to false for your evaluation. The plugin would otherwise abort for using the insecure HTTP protocol once you provide your evaluation Nexus url of http://localhost:8081/nexus. For a production usage, we recommend using the secure HTTPS protocol for your Nexus deployments.

  7. Find out more about the usage in Download Settings from Nexus → Read more…

  8. Activate User Token in the configuration in the Security menu User Token administration by checking the Enabled box and pressing the Save button.

  9. Access your User Profile in the drop-down of your user name in the top right-hand corner of the Nexus user interface.

  10. Use the drop-down in the Profile panel to access User Token.

  11. In the User Token screen, press Access User Token, provide your username and password again, and inspect the tokens in the pop-up dialog.


The distribution of settings.xml is a crucial part of the rollout of Nexus usage. With the help of the the Nexus M2Settings Maven Plugin and the server side settings template, it is possible to automate initial distribution as well as updates to the used settings.xml files. The User Token feature allows you to avoid having SSO credentials exposed in your file system at all.

.NET Integration

The NuGet project provides a package and dependency management solution for .NET developers. It is integrated directly into Visual Studio and makes it easy to add, remove and update libraries and tools in Visual Studio and on the command line for projects that use the .NET Framework. Nexus can act as a proxy between your developer’s Visual Studio instances and the public NuGet Gallery.

When you configure Nexus Pro to act as a proxy for NuGet Gallery you gain a more reliable build that depends on locally cached copies of the components on which you depend. If NuGet Gallery has availability problems, your developers can continue to be productive. Caching components locally will also result in a faster response for developers downloading .NET dependencies.

In this example, you will…

  • Configure your Visual Studio instance to download NuGet packages from your local Nexus server.

  • Consume components from NuGet Gallery via Nexus.

Let’s get started

Your Nexus Pro Trial instance has been preconfigured with the following NuGet repositories:

  • A Proxy Repository for NuGet Gallery

  • A Hosted Repository for your internal .NET components

  • A Group which combines both the NuGet Gallery Proxy and the Hosted NuGet Repository

eval nuget
Figure 8. NuGet Repositories in Repository List Accessed Using the List Filter Feature

To consume .NET components from Nexus you will need to install the NuGet feature in Visual Studio as referenced in Microsoft Visual Studio and NuGet and configure it appropriately:

  1. Open Nexus Pro, click on Repositories in the left-hand navigation menu and locate the NuGet Group repository group. This is the aggregating group from which Visual Studio should download packages. Click on this repository group in the list of repositories.

  2. Select the NuGet tab below the list of repositories with the NuGet Group selected and copy the URL in the Package Source field to your clipboard. The value should be http://localhost:8081/nexus/service/local/nuget/nuget-group/.

  3. Now in Visual Studio, right-click on a Visual Studio project and select Add Library Reference.

  4. In the Add Library Package Reference, click on the Settings button in the lower left-hand corner.

  5. This will bring up an Options button. Remove the initial NuGet repository location and replace it with a reference to your Nexus instance. Clicking Add to add the reference to your Nexus instance.

  6. Click OK to return to the Add Library Package Reference dialog.

  7. Select the Online item in the left-hand side of the dialog. At this point Visual Studio will interrogate your Nexus instance for a list of NuGet packages.

  8. You can now locate the package you need and install it.

  9. To verify that the NuGet package components are being served from Nexus you can return to the Nexus web interface and browse the local storage of your NuGet proxy repository.

Watch this video of the steps being performed in Visual Studio.

The above instructions were created using Visual Studio 10 Web Developer Express. Your configuration steps may vary if you are using a different version of Visual Studio.


When your developers are consuming OSS .NET components through a Nexus proxy of NuGet gallery your builds will become more stable and reliable over time. Every component will be downloaded to Nexus only once, and every following download will enjoy the performance and reliability of a local download from the Nexus cache.

Publish and Share .NET Components with NuGet

Nexus can improve collaboration and control, while increasing the speed of .NET development. NuGet defines a packaging standard that organizations can use to share components.

If your organization needs to share .NET components, you can publish these components to a hosted NuGet repository on Nexus. This makes it easy for projects within your organization to start publishing and consuming NuGet packages using Nexus as a central hub for collaboration.

Once NuGet packages are published to your Nexus instance they are automatically added to the NuGet repository group, making your internal packages as easy to consume as packages from NuGet Gallery.

In this example, you will…

  • Publish NuGet packages to a Hosted NuGet repository.

  • Distribute custom .NET components using Nexus.

Let’s get started:

  1. Follow the example from .NET Integration to set up proxying of NuGet packages from Nexus.

  2. Activate the NuGet API Security Realm → Read more…

  3. Create a NuGet Package in Visual Studio. Creating a package for deployment can be done with the pack command of the nuget command line tool or within Visual Studio. Detailed documentation can be found on the NuGet website.

  4. Publish a NuGet Package to Nexus → Read more…


Once NuGet packages are published to your Nexus instance and are available via a NuGet repository group, your internal packages will be as easy to consume as packages from NuGet Gallery.

This will greatly improve sharing of components and reuse of development efforts across your teams and allow you to modularize your software.


Integration with Enterprise LDAP Solutions

Organizations with large, distributed development teams often have a variety of authentication mechanisms, from multiple LDAP servers with multiple User and Group mappings, to companies with development teams that have been merged during an acquisition. Nexus Pro’s Enterprise LDAP support was designed to meet the most complex security requirements and give Nexus administrators the power and flexibility to adapt to any situation.

Nexus Pro offers LDAP support features for enterprise LDAP deployments including detailed configuration of cache parameters, support for multiple LDAP servers and backup mirrors, the ability to test user logins, support for common user/group mapping templates, and the ability to support more than one schema across multiple servers.

Let’s get started

Read more about configuring Enterprise LDAP to learn about the following:

  • Configuring LDAP caching and timeout.

  • Configuring and testing LDAP failover.

  • Using LDAP user and group mapping templates for Active Directory, POSIX with dynamic or static groups or generic LDAP configuration.

With Enterprise LDAP support in Nexus Pro, you can do the following:

  • Cache LDAP authentication information.

  • Use multiple LDAP servers, each with different User and Group mappings.

  • Use LDAP servers with multiple backup instances and test the ability of Nexus to failover in the case of an outage.

  • Augment the roles from LDAP with Nexus specific privileges.


When you need LDAP integration, you will benefit from using Nexus Pro. Nexus Pro can support the largest development efforts, with some of the most complex LDAP configurations, including multiple servers and support for geographic failover and does so in production with many users every day.

Integration with Atlassian Crowd

If your organization uses Atlassian Crowd, Nexus Pro can delegate authentication and access control to a Crowd server by mapping Crowd groups to Nexus roles.

Let’s get started

  1. Configure the Crowd Plugin → Read more…

  2. Map Crowd Groups to Nexus Roles → Read more…

  3. Add the Crowd Authentication Realm → Read more…


If you’ve consolidated authentication and access control using Atlassian Crowd, take the time to integrate your repository manager with it as well. Nexus Pro’s support for Crowd makes this easy.

Enterprise Deployments

Scaling Nexus Deployments for Distributed Development

Avoid downtime by deploying Nexus in a highly available configuration! With the Nexus Pro feature Smart Proxy, two distributed teams can work with local instances of Nexus that will inform each other of new components as they are published. Smart Proxy is an enhanced proxy setup with push notifications and potential prefetching of components. It allows you to keep proxy repositories on multiple Nexus servers in sync without sacrificing performance.

A team in New York can use a Nexus instance in New York and a team in Sydney can use an instance in Australia. If a component has been deployed, deleted, or changed, the source repository notifies the proxy. Both teams are assured that Nexus will never serve stale content. This simple mechanism makes it possible to build complex distributed networks of Nexus instances relying on this publish/subscribe approach.

In this example, you will…

  • Setup two instances of Nexus Pro.

  • Configure one instance to proxy the hosted instances of the other instance.

  • Configure the proxying instance to subscribe to Smart Proxy events.

Let’s get started

  1. Enable Smart Proxy publishing → Read more…

  2. Establish trust between Nexus instances → Read more…

  3. Configure Smart Proxy for specific repositories → Read more…


With Smart Proxy, two or more distributed instances of Nexus can stay up to date with the latest published components. If you have distributed development teams, Smart Proxy will allow both teams to access a high-performance proxy that is guaranteed to be up to date.

Jump to Line
Something went wrong with that request. Please try again.