Repository Management with Nexus

22.5. Process Improvements

22.5.1. Grouping Repositories

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

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

For example imagine a group in your organization is starting to use components provided by the JBoss release repository available at https://repository.jboss.org/nexus/content/repositories/releases/. The developers are already accessing Nexus via the public group. All you have to do is to create a new proxy repository for the JBoss release repository and add it to the public group and all developers, CI servers and other tools will have access to the additional components.

Want to add the Grails repositories? No problem - proxy them and add them to the group. Proxy Clojars? No problem. How about a repository of a business partner or supplier, that is protected by user credentials? No problem - the same approach applies.

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 approved components including release, snapshots and approved components provisioned via procurement as detailed in Section 22.4.3, “Component Procurement”.

22.5.2. Staging A Release With Nexus

When was the last time you did a software release to a production system? Did it involve a QA sign-off? What was the process you used to re-deploy, 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.

In this example, you will…

  • Configure a project to publish its build output component to Nexus
  • Deploy a release and view the deployed component in a temporary staging repository
  • Promote or discard the contents of this temporary staging repository

Let’s get started using the provided scripts:

  1. This example assumes that you have successfully deployed the simple-project as documented in Section 22.3.1, “Proxying Components”.
  2. Inspect the pre-configured Example Release Profile staging profile by selecting it from the list available after selecting Staging Profiles in the the Build Promotion menu in the left hand navigation
  3. Notice that the version of the simple-project in the pom.xml ends with -SNAPSHOT. This means that it is in development.
  4. Change the version of the simple project to release version by removing the -SNAPSHOT in a text editor or run the command

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

    $ ./build -f simple-project/pom.xml clean deploy
  6. To view the staging repository, click on Staging Repositories in the Build Promotion menu and you should see a single staging repository as shown in this illustration.
  7. Click on Close to close the repository and make it available via the public group.
  8. Experiment with Staging, at this point you can:

    1. Click on Drop to discard the contents of the repository and stag- ing 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
figs/web/eval-staging.png

Figure 22.7. Closing A Staging Repository In Nexus User Interface


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

Alternatively using your own Apache Maven setup:

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

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

    $ mvn clean deploy

22.5.3. Hosting Project Web Sites

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

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

You can use this feature internally, but it is even better suited if you are providing an API or components for integration. You can host full project web sites 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 web site to Nexus Professional

Let’s get started using the provided scripts:

  1. Create a hosted repository with the Site format and a Repository ID called siteRead more…
  2. Deploy the simple-project component and site to Nexus

    $ ./build -f simple-project/pom.xml clean deploy site-deploy
  3. Browse the generate site on Nexus at http://localhost:8081/nexus/content/sites/site/
  4. Optionally configure your own Maven project to deploy a site to Nexus → Read more…
  5. And publish it to Nexus → Read more…

Alternatively using your own Apache Maven setup:

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

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

22.5.4. Process and Security Improvements With Maven Settings Management And User Token

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

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

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

In this example, you will…

  • Explore the configuration of a Maven Settings template in Nexus Professional
  • Activate and access your user token

Let’s get started

  1. Log into Nexus as administor and access the Maven Settings administration via the item in the Enterprise menu
  2. Press the Add button, provide a name and edit the new settings file
  3. Add the server section

    <servers>
        <server>
          <id>nexus</id>
          <!-- User-token: ${userToken} -->
          <username>${userToken.nameCode}</username>
          <password>${userToken.passCode}</password>
        </server>
      </servers>
  4. Read more about potential configuration and usage in Manage Maven Settings Templates → Read more…
  5. Downloading the settings template requires Nexus running via https and can then be performed with

    mvn org.sonatype.plugins:nexus-m2settings-maven-plugin:1.4:download -Dsecure=false

    and following the prompts

  6. Note that the secure option is set to false for your evaluation. The plugin would otherwise abort for using the insecure http protocol once you provide your evaluation Nexus url of http://localhost:8081/nexus. For a production usage we recommend using the secure https protocol for your Nexus deployments.
  7. Find out more about the usage in Download Settings from Nexus → Read more…
  8. Activate User Token in the configuration in the Security menu User Token administration by checking the Enabled box and pressing the Save button
  9. Access your User Profile in the drop down of your user name in the top right hand corner of the Nexus user interface
  10. Use the drop down in the Profile panel to access User Token
  11. In the User Token screen press Access User Token, provide your username and password again and inspect the tokens in the pop up dialog