Prerequisites and Preparation

{inall}

The following guide for evaluating {pro} is based on an assumption of installing the repository manager itself as well as the various technologies used in the specific evaluation example all on one computer. A more extended evaluation of {pro} 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 the {pro}.

Besides the installation of the repository manager 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 {pro}.

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 ~	cd %HOMEPATH%
Script invocation	./build	build.bat
Gradle Wrapper script invocation	./gradlew	gradlew.bat

Java Runtime

{nxrm} 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 8 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)

Warning

{pro} and {oss} require 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"

Gradle

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 {nxrm}. 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 {pro}. A lot of the core features are available in {oss} as well and some examples are suitable to assess with {oss}.

Step 1: Download the {pro} Trial Installer for your operating system.
Step 2: Run the {pro} Trial Installer.
Step 3: Start the {pro} from the {pro} Trial Installer.

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

Note	This guide and the examples reference the 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 several directories to know:

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

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

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

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

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

<nexus_work>/logs/nexus-launcher.log
<nexus_work>/logs/nexus.log

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

<nexus_install>/conf/nexus.properties

Edit the line that looks like this:

application-port=8081

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

application-port=9090

Save the file and restart the repository manager.

Activating Your {pro} Trial

Once the repository manager 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 {pro} Trial License,” which contains your trial license key. Paste this license key into the license field in the {pro} user interface. Click 'Activate' to activate your 14-day {pro} trial. Once your trial is activated, you will be presented with the user interface.

Logging in as an Administrator

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

Figure 1. {pro} User Interface with Login

The default administrator username is admin and password is admin123.

The {pro} Trial evaluation guide assumes that you are logged in as an administrator.

Getting Started with Your {pro} Evaluation

To make it easier to evaluate {pro}, we’ve created a set of projects to demonstrate the features of {oss} and {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 https://github.com/sonatype/nexus-book-examples for you to download and inspect separately, if desired. The latest version of all the examples is available as a zip archive at https://github.com/sonatype/nexus-book-examples/archive/master.zip.

When you downloaded the trial distribution of {pro}, your server is also preconfigured to demonstrate important features.

The trial distribution contains the following customizations:

{pro} has been preconfigured to download the search index from the Central Repository.
A Staging profile has been configured to demonstrate release management.
{pro} proxies NuGet Gallery so that you can quickly evaluate support for .NET development.

The Basics: Proxying and Publishing

{inall}

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.

— Build Engineer
Financial Industry

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 {nxrm} can help. {nxrm} is preconfigured to proxy the Central Repository, and other remote repositories can be easily added. Once set up, the repository manager 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 the repository manager. 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 the repository manager.
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.

Go to the evaluation guide directory you configured during the {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
```

As the project builds, you will notice that all components are downloaded from your local repository manager instance installed with requests from Apache Maven:

Downloading: http://localhost:8081/nexus/content/groups/public/org
  /apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Downloaded: http://localhost:8081/nexus/content/groups/public/org
  /apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
  (4 KB at 1.3 KB/sec)
...

Here are examples from Gradle:

Download http://localhost:8081/nexus/content/groups/public/org/
  codehaus/jackson/jackson-core-asl/1.8.0/jackson-core-asl-1.8.0.jar
Download http://localhost:8081/nexus/content/groups/public/org/
  codehaus/jackson/jackson-mapper-asl/1.8.0/jackson-mapper-asl-1.8.0.jar
Download http://localhost:8081/nexus/content/groups/public/com/
  google/sitebricks/sitebricks-converter/0.8.5/sitebricks-converter-0.8.5.jar
...

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

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
```
Notice how the downloads are occurring much faster. The components are no longer retrieved from the remote repositories before being served by the repository manager, but they are supplied straight from the proxy repository cache.
To verify that components are being cached in the repository manager, open the Repositories panel by clicking on 'Repositories' in the left-hand main 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 the repository manager.

Alternatively using your own Apache Maven setup:

Ensure that Apache Maven is installed as a prerequisite as documented in Apache Maven.
Go to the evaluation guide directory you configured during the {pro} install and configure Maven to access the repository manager 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 trial installer.
```
$ cp maven/settings/settings.xml ~/.m2/
```
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.
Build the simple-project, and observe the downloads from the repository manager.
```
$ cd maven/simple-project/
$ mvn clean install
```
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 the repository manager.
```
$ rm -rf ~/.m2/repository
```

Conclusion

Your builds will be faster and more reliable now that you are caching components in {pro} and retrieving them from there. Once {pro} 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 the repository manager.

Publishing Components

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

With {pro} you create hosted repositories, giving you a place to upload your own component. 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 {pro}.
Watch another project download this component as a dependency from the repository manager.

Let’s get started using the provided scripts:

Follow the proxying evaluation example from Proxying Components.
Go to the evaluation guide directory and publish the simple-project to the repository manager 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
```
The simple-project has been preconfigured to publish its build output in the form of a JAR component to your local instance of {pro}.

Observe how the build tools log the deployment to the repository manager, e.g., Maven

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

Gradle

Uploading:
org/sonatype/nexus/examples/simple-project/1.0-SNAPSHOT/
  simple-project-1.0-20130306.173412-1.jar
to repository remote at
http://localhost:8081/nexus/content/repositories/snapshots

or Ivy

[ivy:publish] :: publishing :: org.sonatype.nexus.examples#simple-project
[ivy:publish] 	published simple-project to http://localhost:8081
  /nexus/content/repositories/snapshots/org/sonatype/nexus/examples/
  simple-project/1.0-SNAPSHOT/simple-project-1.0-SNAPSHOT.jar

To verify that the simple-project component was deployed to repository manager, click on Repositories and then select the Snapshots repository. Select the Browse Storage tab as shown in this illustration.

Figure 2. Successfully Deployed Components in the Snapshots Repository
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
```

This second project has a dependency on the first project declared in the Maven pom.xml with

<dependency>
  <groupId>org.sonatype.nexus.examples</groupId>
  <artifactId>simple-project</artifactId>
  <version>1.0.0-SNAPSHOT</version>
</dependency>

and in the Gradle build.gradle file as

dependencies {
    compile "org.sonatype.nexus.examples:simple-project:1.0.0-SNAPSHOT"
}

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

<dependencies>
  <dependency org="org.sonatype.nexus.examples" name="simple-project"
      rev="1.0.0-SNAPSHOT"/>
</dependencies>

During the build, it is relying on the repository manager 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.

Conclusion

{oss} and {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.

Governance

{inrmonly}

Identify Insecure OSS Components In {pro}

The Repository Health Check in {pro} turns your repository manager into the first line of defence against security vulnerabilities. {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. The repository manager becomes an effective way to discover flawed components in your repositories allowing you to avoid falling victim to known exploits.

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

Follow the proxying examples in The Basics: Proxying and Publishing to seed the Central proxy repository of your repository manager instance. These examples include several components with security vulnerabilities and license issues as dependencies.
Once your repository manager instance has cached the components, open the user interface, log in as administrator and click on the green Analyze button next to your Central proxy repository.
After the completion of the analysis, the button will change into an indicator of the number of security and license issues found.
Hover your mouse over the indicator and the repository manager will show you a summary report detailing the number and type of security vulnerabilities present in you repository.
Optionally, build some of your own applications to get further components proxied and see if additional security issues appear.

Figure 4. Security Vulnerability Summary Display from Repository Health Check

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

Conclusion

The Repository Heath Check of {pro} 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 {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

Follow the proxying examples in The Basics: Proxying and Publishing to seed the Central proxy repository of your {pro} instance. These examples include several components with security vulnerabilities and license issues as dependencies.
Once your repository manager instance has cached the components, log in to the user interface as administrator and click on the green 'Analyze' button next to your 'Central' proxy repository in the 'Repositories' list.
After the completion of the analysis, the button will change into an indicator of the number of security and license issues found.
Hover your mouse over the indicator and the repository manager will show you a summary report detailing the number and type of license issues of components present in you repository.
Optionally, build some of your own applications to get further components proxied and see if additional license issues appear.

Figure 5. License Analysis Summary Display from Repository Health Check

{oss} and the trial version show the summary information found by the analysis.

{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 {pro} provides specific information about licenses and security vulnerabilities. A detailed walkthrough of this report is available on the Sonatype website.

Figure 6. Repository Health Check Details with License Issues List

Conclusion

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 {pro}’s Repository Health Check.

Process Improvements

Grouping Repositories

{inall}

Once you have established {pro} and set up your build, provisioning system, and other tools to connect to the repository manager, you can take advantage of repository groups. The best practice to expose {pro} 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 the repository manager 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 https://repository.jboss.org/nexus/content/repositories/releases/. The developers are already accessing the repository manager 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.

Conclusion

Using groups allows you to expose multiple repositories, mix snapshot and release components and easily administrate it all on the {pro} 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 {pro}

{inrmonly}

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 {pro}.
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:

This example assumes that you have successfully deployed the simple-project as documented in Proxying Components.
Inspect the preconfigured 'Example Release Profile' staging profile by selecting it from the list available after selecting 'Staging Profiles' in the 'Build Promotion' menu in the left-hand navigation.
Notice that the version of the simple-project in the pom.xml ends with -SNAPSHOT. This means that it is in development.
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
```

Publish the release to the Staging suite with

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

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.
Click on 'Close' to close the repository and make it available via the public group.
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.
Once you release the staging repository, you will be able to find the release components in the 'Releases' hosted repository.

Figure 7. Closing a Staging Repository in the 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:

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
```
And publishing to the Staging suite with
```
$ mvn clean deploy
```

Conclusion

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

{inall}

{pro} and {oss} 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 the repository manager and deploy the project site.

With the repository manager 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 {pro}.

Let’s get started using the provided scripts:

Create a hosted repository with the 'Site' format and a 'Repository ID' called 'site' → Read more…
Deploy the simple-project component and site to the repository manager:
```
$ ./build -f simple-project/pom.xml clean deploy site-deploy
```
Browse the generate site on the repository manager at http://localhost:8081/nexus/content/sites/site/
Optionally, configure your own Maven project to deploy a site to the repository manager → Read more…
Publish it to the repository manager → Read more…

Alternatively using your own Apache Maven setup:

Follow the steps described above with the modification of deploying the site with
```
$ cd maven/simple-project
$ mvn clean deploy site-deploy
```

Conclusion

If your projects need to publish HTML reports or a project web site, {pro} and {oss} provide a consolidated target for publishing project-related content.

Process and Security Improvements with Maven Settings Management and User Token

{inrmonly}

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

The User Token feature of {pro} allows you to replace the SSO username and password with {pro}-specific tokens that are autogenerated and managed by the repository manager.

Furthermore, the Nexus Maven Settings Management allows you to manage Maven Settings. Once you have developed a Maven Settings template, developers can connect to {pro} using the Nexus M2Settings Maven plugin that will take responsibility for downloading a Maven Settings file from the repository manager 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 {pro}.
Activate and access your user token.

Let’s get started

Log into the repository manager as administor and access the 'Maven Settings' administration via the item in the 'Enterprise' menu.
Press the 'Add' button, provide a name and edit the new settings file.

Add the server section:

<servers>
    <server>
      <id>nexus</id>
      <!-- User-token: $[userToken] -->
      <username>$[userToken.nameCode]</username>
      <password>$[userToken.passCode]</password>
    </server>
  </servers>

Read more about potential configuration and usage in Manage Maven Settings Templates
Downloading the settings template requires {pro} 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
```
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 {pro} URL of http://localhost:8081/nexus. For a production usage, we recommend using the secure HTTPS protocol for your {pro} deployments.
Find out more about the usage in Download Settings from the repository manager → Read more…
Activate User Token in the configuration in the 'Security' menu 'User Token' administration by checking the 'Enabled' box and pressing the 'Save' button.
Access your 'User Profile' in the drop-down of your user name in the top right-hand corner of the user interface.
Use the drop-down in the 'Profile' panel to access 'User Token'.
In the 'User Token' screen, press 'Access User Token', provide your username and password again, and inspect the tokens in the pop-up dialog.

Conclusion

The distribution of settings.xml is a crucial part of the rollout of repository manager usage. With the help of 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

{inall}

Consume .NET Components from NuGet Gallery

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. {pro} can act as a proxy between your developer’s Visual Studio instances and the public NuGet Gallery.

When you configure {nxrm} 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 repository manager.
Consume components from NuGet Gallery via {pro}.

Let’s get started

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

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

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

Open {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.
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/.
Now in Visual Studio, right-click on a Visual Studio project and select 'Add Library Reference'.
In the 'Add Library Package Reference', click on the 'Settings' button in the lower left-hand corner.
This will bring up an 'Options' button. Remove the initial NuGet repository location and replace it with a reference to your repository manager instance. Clicking 'Add' to add the reference.
Click 'OK' to return to the 'Add Library Package Reference' dialog.
Select the 'Online' item in the left-hand side of the dialog. At this point Visual Studio will interrogate your repository manager for a list of NuGet packages.
You can now locate the package you need and install it.
To verify that the NuGet package components are being served from {pro} you can return to the web interface and browse the local storage of your NuGet proxy repository.

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.

Conclusion

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

Publish and Share .NET Components with NuGet

{pro} 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 the repository manager. This makes it easy for projects within your organization to start publishing and consuming NuGet packages using {pro} as a central hub for collaboration.

Once NuGet packages are published to your repository manager 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 {pro}.

Let’s get started:

Follow the example from .NET Integration to set up proxying of NuGet packages from the repository manager.
Activate the NuGet API Security Realm → Read more…
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.
Publish a NuGet Package to {pro} → Read more…

Conclusion

Once NuGet packages are published to your {pro} 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.

Security

Integration with Enterprise LDAP Solutions

{inall}

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. {pro}’s Enterprise LDAP support was designed to meet the most complex security requirements and give administrators the power and flexibility to adapt to any situation.

{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 {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 {pro} to failover in the case of an outage.
Augment the roles from LDAP with {pro} specific privileges.

Conclusion

When you need LDAP integration, you will benefit from using {pro}. {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

{inrmonly}

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

Let’s get started

Configure the Crowd Plugin → Read more…
Map Crowd Groups to {pro} Roles → Read more…
Add the Crowd Authentication Realm → Read more…

Conclusion

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

Enterprise Deployments

{inrmonly}

Scaling {pro} Deployments for Distributed Development

Avoid downtime by deploying {pro} in a highly available configuration! With the {pro} feature Smart Proxy, two distributed teams can work with local instances of the repository manager 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 repository managers in sync without sacrificing performance.

A team in New York can use a {pro} 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 the repository manager will never serve stale content. This simple mechanism makes it possible to build complex distributed networks of repository manager instances relying on this publish/subscribe approach.

In this example, you will…

Setup two instances of {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

Enable Smart Proxy publishing → Read more…
Establish trust between repository managers → Read more…
Configure Smart Proxy for specific repositories → Read more…

Conclusion

With Smart Proxy, two or more distributed instances of {pro} 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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chapter-eval.asciidoc

chapter-eval.asciidoc

Prerequisites and Preparation

A Note about the Operating System

Java Runtime

Apache Maven

Gradle

Apache Ant and Apache Ivy

Microsoft Visual Studio and NuGet

Getting Started

Activating Your {pro} Trial

Logging in as an Administrator

Getting Started with Your {pro} Evaluation

The Basics: Proxying and Publishing

Proxying Components

Publishing Components

Governance

Identify Insecure OSS Components In {pro}

Track Your Exposure To OSS Licenses

Process Improvements

Grouping Repositories

Staging a Release with {pro}

Hosting Project Web Sites

Process and Security Improvements with Maven Settings Management and User Token

.NET Integration

Consume .NET Components from NuGet Gallery

Security

Integration with Enterprise LDAP Solutions

Integration with Atlassian Crowd

Enterprise Deployments

Scaling {pro} Deployments for Distributed Development

Files

chapter-eval.asciidoc

Latest commit

History

chapter-eval.asciidoc

File metadata and controls

Prerequisites and Preparation

A Note about the Operating System

Java Runtime

Apache Maven

Gradle

Apache Ant and Apache Ivy

Microsoft Visual Studio and NuGet

Getting Started

Activating Your {pro} Trial

Logging in as an Administrator

Getting Started with Your {pro} Evaluation

The Basics: Proxying and Publishing

Proxying Components

Publishing Components

Governance

Identify Insecure OSS Components In {pro}

Track Your Exposure To OSS Licenses

Process Improvements

Grouping Repositories

Staging a Release with {pro}

Hosting Project Web Sites

Process and Security Improvements with Maven Settings Management and User Token

.NET Integration

Consume .NET Components from NuGet Gallery

Publish and Share .NET Components with NuGet

Security

Integration with Enterprise LDAP Solutions

Integration with Atlassian Crowd

Enterprise Deployments

Scaling {pro} Deployments for Distributed Development