25.5. Process Improvements

25.5.1. Grouping Repositories

Available in Nexus Repository OSS and Nexus Repository Pro

Once you have established Nexus Repository Manager 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 Nexus Repository Manager Pro is to get users to connect to the Public Repositories group as configured in the settings.xml as documented in Section 25.3.1, “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.

25.5.2. Staging a Release with Nexus Repository Manager Pro

Available in Nexus Repository Pro only

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 Repository Manager 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:

  1. This example assumes that you have successfully deployed the simple-project as documented in Section 25.3.1, “Proxying Components”.
  2. 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.
  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 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.

Figure 25.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:

  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 Staging suite with

    $ mvn clean deploy

25.5.3. Hosting Project Web Sites

Available in Nexus Repository OSS and Nexus Repository Pro

Nexus Repository Manager Pro and Nexus Repository Manager 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 Nexus Repository Manager 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 the repository manager:

    $ ./build -f simple-project/pom.xml clean deploy site-deploy
  3. Browse the generate site on the repository manager at http://localhost:8081/nexus/content/sites/site/
  4. Optionally, configure your own Maven project to deploy a site to the repository manager → Read more…
  5. Publish it to the repository manager → 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

25.5.4. Process and Security Improvements with Maven Settings Management and User Token

Available in Nexus Repository Pro only

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 Nexus Repository Manager Pro allows you to replace the SSO username and password with Nexus Repository Manager 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 Nexus Repository Manager 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 Nexus Repository Manager Pro.
  • Activate and access your user token.

Let’s get started

  1. Log into the repository manager 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 Repository Manager 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
  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 Repository Manager Pro URL of http://localhost:8081/nexus. For a production usage, we recommend using the secure HTTPS protocol for your Nexus Repository Manager Pro deployments.
  7. Find out more about the usage in Download Settings from the repository manager → 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 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.