{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}.
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.
| 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 |
{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 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 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 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.
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.
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.
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.
The default administrator username is admin and password is admin123.
The {pro} Trial evaluation guide assumes that you are logged in as an administrator.
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.
{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.
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.
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
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.
{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.
{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.
{inrmonly}
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.
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.
{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 {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.
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.
{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.
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.
{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.
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.
{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:
-
Click on 'Drop' to discard the contents of the repository and be able to stage another release.
-
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.
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
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.
{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
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.
{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.
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.
{inall}
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
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.
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.
{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…
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.
{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.
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.
{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…
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.
{inrmonly}
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…
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.