Installing Nexus on Ubuntu 11.10 and Tomcat 6 Part 2

Posted by: TomS on April 15, 2012 @ 8:58 pm

NexusIn Part 1 of this post, I covered performing a basic installation of Nexus in a Tomcat servlet container on Ubuntu 11.10.  Now I’m going to cover the details of configuring Nexus.

Nexus is a repository that can be used with tools such as Maven to index and store artifacts for dependency management across projects.  I like to use the Nexus/Maven combo for three main reasons:

  1. Storing Versions of My Own Artifacts – I try to do all my Java builds in Maven these days.  This means that all my projects always have a standard lifecycle and release procedures.  I can commit my code to SVN, but its also nice to have a repository to store my compiled artifacts.  Nexus fills this job, allowing me to deploy all versioned projects to the central repository, accessible from all of my machines.  Additionally, the repository makes all these versioned artifacts available as dependencies for any of the other projects I work with.
  2. Proxying Other Repositories – When you work with Java Maven projects, you’ll get pretty used to Maven “downloading the internet” the first time you build a particular project on a machine.  This is Maven getting all the dependencies and transitive dependencies required to build your project.  It might take a little while, but its far better than trying to manage all those dependencies yourself.  This step is often dependent on external repositories outside of my control, however.  The external repositories may gone down (but rarely), and it is common for these repositories to eventually remove old versions of artifacts or reorganize their repositories.   Proxying a repository means that my Maven builds will always fetch artifacts from my Nexus repository first.  If Nexus can’t find the artifact, it will download it from the external repository, but it will store it locally so future requests do not depend on the external repository.  This means that the artifacts I use never go away, and the process is much faster since I only need to retrieve artifacts from my own repository in most cases.
  3. Hosting 3rd Party Artifacts – There are times when I use a jar, but the jar isn’t readily available in a Maven repository somewhere.  I try to avoid just adding those jars to SVN.  Instead, I’ll upload the artifacts to Nexus and I can access them as needed via standard Maven builds.

Cleaning up Nexus

First things first.  Nexus gives you a pretty nice setup out of the box, but there’s a few auto-configured repositories I simply don’t want.  The first of these is the shadow repository.

For compatibility purposes, Nexus will allow you to shadow another repository as a different format.  i.e. you can make your Maven 2 repo look like a Maven 1 repo.  I don’t use Maven 1, so the shadow repository is the first thing to go.  To do this, simply log in as the admin user, click on Repositories on the left side, then select the shadow repository and hit Delete on the toolbar.

Nexus also automatically sets up Proxies to a few locations on the web.  Maven central is a key repo to proxy, so I’ll leave that alone.  There are default proxies set up for Apache Snapshots and Codehaus Snapshots however.  I prefer not to use snapshot jars, so I’m going to remove these.  Using the steps detailed below, you can easily add them back later.

Nexus also comes pre-configured with a Public group, which groups together several proxies.  I’m going to create my own group later with the permissions I want, so the group is the last thing to go.

I’m now left with 1 proxy repository to Maven central and 3 hosted repositories for releases, snapshots, and 3rd party jars.  This is a pretty clean canvas to work on, so I’ll move on to setting up a few more proxy repositories next.

Creating Proxy Repositories

As I mentioned above, Nexus comes pre-configured with a proxy to Maven Central.  This will give you access to almost all dependencies you’ll ever need, but you may find yourself in a situation where you’d like to get artifacts from a repository other than central.  In my case, I’ve often used artifacts from Fusesource.  These guy provide commercial support for several Apache products and do an excellent job bundling more frequent releases of the Apache projects to address bug issues.

Fusesource provides all their artifacts via a Maven repository, so I’m going to set up Nexus with a proxy to their repository.

Creating a proxy is pretty easy, just go to Repositories on the left side of Nexus and then click Add and choose Proxy Repository.  Fill out the following fields, the rest can be left as defaults.

  • Repository ID – I used fusesource, this name is used in the URL for the repository
  • Repository Name – I again used fusesource, this is the display name for the repo in Nexus
  • Remote Storage Location – Use the URL of the remote Maven repository you will proxy, for Fusesource it’s

The rest of the settings can be left as defaults.  It should look something like the screenshot below when you’re done.

Nexus Proxy Repository

Nexus Proxy Repository

Creating Nexus Groups

I’m also going to use Nexus to host Snapshots and Releases of my own artifacts and upload 3rd party artifacts that I can’t find hosted anywhere else.  Fortunately, Nexus’s defaults for these repositories are OK by me.

Breaking things down by repository is nice, but at the end of the day, I want the simplest Maven configuration possible to access the artifacts in my repositories.  Nexus’s concept of groups is a great way to simplify a complex repository storage scheme.

The general idea with groups is that a Group is a super-repo that consists of all the contents of multiple repos.  My preferred setup is to have one group that encapsulates all the repositories I use.  In this way, my Maven configuration simply ends up being one mirror that mirrors all repositories (more on this at the end of this post).

Creating a group only requires a few short steps.  First go the the Repositories Nexus Page, click Add on the menu at the top, then choose Repository Group.

Fill out the following fields:

  • Group ID: the ID of the group that will be used in the URL (I used allrepos)
  • Group Name: the display name that will be used inside Nexus (I used allrepos)
  • Provider: choose Maven2
  • Publish URL: choose True

You then want to add all the repositories that the group should use in a prioritized order.  Repos at the top of the list will override other repos at the bottom of the list if there is a collision.  I use my All Repos group to group all my repositories, and I make sure that the repos I manage are at the top of the list.

Nexus Group Configuration

Nexus Group Configuration

Securing Nexus

I am using Nexus exclusively on my home network, so securing it is not vital, but you may want to make it so only authorized users can access your Nexus repository.  I am going to setup Nexus to disable anonymous access and require authenticated users to view and interact with repos.

First up, I’m going to remove the anonymous access.  To do this, I went to the Security panel on the left and chose Users.  I then selected the anonymous user, changed the Status to disabled and hit Save.  While I was at it, I also disabled the default “deployment” user, as I’ll be creating my own account with similar permissions.

Next up is setting up the permissions to my repositories.  Nexus can be a bit of a pain to configure, but the model is pretty easy to follow.  Nexus has a set of defined Privileges, which enumerate individual permissions such as Read/Write on a Repo, or searching in the web interface.   There are then Roles which combine sets of Privileges together into more manageable chunks.  Roles can also be nested within each other.

The first thing I’m going to do is set up privileges for the repos that I’ll be working with.  These repos are the repos I would typically deploy to (3rd party, release, snapshot), and the new All Repos group that I created.  (Note Nexus uses “All Repositories” in its built-in privileges to distinguish a privilege that works on all repositories in Nexus.  Make sure you distinguish this from the All Repos group I created [bad naming on my part]).

For each one of these, I went to the Privileges screen and chose Add Repository Target Privilege.  I then filled out a Name, Description, and chose the given Repository.  For Repository Target, I left things to All, implying that this includes all artifacts and data in the repository.  Adding these Privileges creates a set of CRUD (create,read,update,delete) privileges for each repository which you can now use to create a larger role.

I’m going to create two Roles, developer and deployer.  It’s intended that developer will be able to use Nexus in read only mode, while the deployer will also be able to add artifacts to the repository.

Creation of Roles is done via the Roles page under the Security Menu.  Simply go to the page and click add.  You’ll have to add a role id, name, and description, similar to all other entities in Nexus.

For my developer (read only) Role, I added the following Privileges.

  • Nexus Developer Role (I piggy back off Nexus’s predefined role to give this role the general privileges to log in to nexus and view repositories).
  • All Repos – (view)
  • All Repos Group – (read)
Note that I only gave read permissions to the All Repos group that I set up.  This is because a developer only needs to download artifacts from the repository, and All Repos already has all the artifacts the developer would need.  (view) is a default Privilege that Nexus sets up that allows a user to view a repo within Nexus, while the (read) Privilege is part of the CRUD set which relates back to REST calls on the repository.  Essentially, (read) allows you to download artifacts from the repository.
For my deployer (read/write) Role, I added the following Privileges.
  • Nexus Developer Role (I piggy back off Nexus’s predefined role to give this role the general privileges to log in to nexus and view repositories).
  • All Repos – (view)
  • All Repos Group – (read)
  • 3rd Party – (create,delete,read,update,view)
  • Releases – (create,delete,read,update,view)
  • Snapshots – (create,delete,read,update,view)
  • Artifact Upload
This user has a bunch of additional Privileges when compared to the developer Role i created.  When this type of user gets artifacts, it will still be via the All Repos group, so read only access is still the only thing required there.  When the user deploys or modifies artifacts, however, he/she will need read/write privileges on the destination repos.  I also added the Artifact Upload Privilege which enables a nice tool to upload artifacts directly with the Nexus UI.
The last step in securing Nexus is to add users.  I’m going to add one deployer User (myself) and a test developer User just to make sure I’ve got it configured correctly.
You can  add users via the Security > User page. Make sure you fill out
  • User ID – the login id to use
  • Email – for password resets and stuff
  • Active – make this Active
  • Password/Confirm Password – The password for this account
  • Roles – The roles to add.
Since I’ve created high level roles, my Deployer User gets simply the Deployer Role, and my Developer User get simply the Developer Role.
Nexus Configuring Users

Nexus Configuring Users

A quick test of the security scheme is probably in order.  Here’s a few quick steps to make sure everything is working.

  • Log out of Nexus – You should see a warning saying “Warning: Could not retrieve Nexus status, anonymous access might be disabled.”  This ensures anonymous access was disabled.
  • Log in as the Developer User – You should be able to navigate to the repositories and see only the All Repos group.
  • Log in as the Deployment User – You should be able to navigate to the repositories and see the All Repos group as well as 3rd Party, Releases, and Snapshots repos.  Additionally, you should see the option to upload artifacts to 3rd Party, Releases, and Snapshots.

Configuring Maven and Testing It All Out

The server side of nexus is now configured, but you’ll still need to configure each of your machines so that they are aware of Nexus.  Maven handles configuration via a settings.xml file in the .m2 directory in your user home directory.  On linux/unix this would typically be something like /home/tom/.m2/settings.xml and on Windows you might see something like C:\Users\tom\.m2\settings.xml.

As I mentioned previously, the single Group makes configuration pretty simple.  I’m just going to set up a mirror entry in my configuration that says for all repos ever defined, always go through my personal Nexus mirror.  Since I password protected my Nexus group, I’ll also need to specify the login/password to use when connecting to the repo.  My settings.xml file looks like this:

<settings xmlns=""
            <name>Home Mirror</name>

There are a few important things to note in this config.

  • The URL of your mirror should match the URL of the group you created in Nexus.  You can find it by looking at the Repositories page in Nexus.
  • The id of your mirror should correspond to the id of a server where you specify your login/password for the mirror (I used home).
  • You should have server entries for each of the repos you may eventually deploy too.
  • The username/password should match the username password of a user you create in Nexus that at least has read privileges to the group.

To make sure that I’ve got everything configured correctly, I’m going to walk through the standard process of creating a project from a maven archetype, building it, and deploying it.  First though, I want to start from a clean slate with my Nexus repo, so I delete everything in the .m2/repository directory.

I then switched to a temporary directory and ran the following command:

mvn archetype:generate -DartifactId=HelloWorld -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

This creates a simple  project.  You should note that when downloading all the required dependencies, Maven actually uses the URL of the All Repos group and not Maven Central.

Before we begin, I’m going to modify the project, and add a distributionManagement element specifying that snapshots should be deployed to my snapshot repo, and releases should be deployed to my releases repo.  To do this I modified the pom.xml in the project and added the following:


Note how the id’s used match up to the ids specified in settings.xml.  Maven will use this to determine the password to use when deploying artifacts.  The URLs should also match the URLs of the individual repos (not the group) in Nexus.

Next up, run install the project to your local repo to make sure it compiles.

mvn install

The project should build successfully.  Now you can deploy the project, which is currently in snapshot mode.

mvn deploy

If the deployment was successful, you’ll see a message in the console saying your artifact was uploaded to the URL of your snapshot repository.  You should be able to go to Nexus now, browse the Snapshot repository, and see your newly deployed artifact.  This will confirm that you can deploy to the Snapshot repository.

I now want to test deployment to the Release repository.  To do this, I simply go into the pom.xml and update the version from 1.0-SNAPSHOT to 1.0.  The I deploy the artifact again.

mvn deploy

If the deployment was successful, you’ll see a message in the console saying your artifact was uploaded to the URL of your release repository this time.  You should be able to go to Nexus now, browse the Release repository, and see your newly deployed artifact.  This will confirm that you can deploy to the Release repository.

At this point everything is working.  You may want to go into Nexus and delete the artifacts that you have uploaded as part of the test.  From here on it, you can use Nexus to manage your dependencies.  If I get a chance, I may add a Part 3 to this article soon discussing some of the maintenance jobs and additional configuration options you may want to turn on in Nexus.


3 responses to “Installing Nexus on Ubuntu 11.10 and Tomcat 6 Part 2”

  1. […] Part 2 of this article is now available. Filed under: Technology | Tags: apache, maven, nexus, tomcat, ubuntu | Comments (1) […]

  2. Many thanks for the articles – both this one and the previous have been invaluable when setting up Nexus on Ubuntu (previously I had only deployed on Glassfish running on Windows)

    Thanks also for a very thorough walk through – not only did I get nexus up and running, but I learnt a lot of new stuff as well!

    Best wishes,


  3. Jimmy Ljungberg says:

    Thank you for excellent instructions and explanations. Because of you I managed to setup a working solution at work (no internet access) and helping my colleagues out :-)

Leave a Reply