Nexus Migration Guide

This guide is here for project's release managers. It explains what have to be done in order to properly perform a release on the OW2 Nexus instance.
Nexus administrators should read the admin guide to setup Nexus for a new project.


OW2 has installed a Nexus maven repository manager to provide a better management of the maven development process.

You can browse it here :
It offers advanced repository hosting capabilities such as staging, releases validation before central synchronization, ...
You can read more on Sonatype's web site:

As a consequence, OW2 won't maintain the old repository anymore.

Disengagement will be done in 3 phases:

  1. Repository will be read only
    • Projects will no more be able to deploy artifacts to release and snapshot repository
  2. Repository content will be transfered into Nexus
    • Dedicated hosted repositories will be created for each old repository
    • URL redirection will be setup so that old URLs will be redirected to new nexus hosted repositories
  3. Repository will be deleted
    • Soon after repository transfert, as nobody will be able to access the old content, we will be able to safely delete that content (hosted repositories in nexus still being available)

Read-only mode for repositories will be performed at the end of October (in 3 monthes at the date of writing).

The migration of projects starts right now (Nexus being already fully functional) !
Release managers must open a JIRA on the OW2 Service Desk project (component NEXUS) to setup the appropriate permissions before trying to release.
They have to provide the name of the project for which they apply for.

Releases managers also have to read this guide before their first release.


Staging is a mechanism provided by Nexus helping to manage quality of the releases.
Once the release has been performed (using the maven release plugin), the artifacts are still not publicly available in the release repository.
A temporary repository (containing only the artifacts of the release) is managed by Nexus.

When all the artifacts are in this staging repository, it has to be manually closed (using nexus web interface).
Once closed, you cannot add artifacts anymore. But there is more: when closing, a set of rules is applied to the artifacts to check their conformance (see below).

If the rules applies cleanly (without errors), then the staging repository can be released (using nexus web interface).
At this moment, the team can check the release. If they think something gone wrong, the staging repository can be deleted and a new staging process can begin again.

Once the staging repository has been released, artifacts flow to the release repository and are then synched into central.

First Release (Devs)

Before performing the first project's release on Nexus, a couple of changes need to be done.



Releases Managers can only releases using a Maven v2.2.x or Maven 3.x (due to some GPG signatures issues).


Changing Parent's POM

Any released module must inherit (directly or indirectly) from the OW2 organizational POM (GAV : org.ow:ow2).

At the time of writing, the latest version of this POM is 1.3.
<project xmlns=""


 <!-- ... -->



All released artifacts must be signed with a GPG key.

Release Managers must read the Maven/GPG documentation. They should not forget to distribute their public key to key servers.

POM Rules

Theses rules applies to the parent POM of the staged artifacts (for a multi-module project).


Project POM must have the following elements:

  • <modelVersion>
  • <groupId>
  • <artifactId>
  • <version>
  • <packaging>
  • <name>
  • <description>
  • <url>
  • <licenses>
  • <scm><url>
  • <scm><connection>
  • <developers>

No Releases Repositories

This rule is currently not applied yet for central synchronization (but might be in the future).
As a consequence, the OW2 Nexus repository will also not apply this rule.

But it is a good idea to start thinking about this problem right now emoticon_smile

The set of rules deployed on Nexus states that no release repository other than central should be declared in the POMs.
This is because central has to be self-contained.

This rule do not apply to snapshot repositories, but as everyone know, a released project shouldn't (and cannot) depends on not released artifacts.

This is a very important point and is the one that could make the migration difficult, since all project's dependencies may not be in central.
If this happen, you have a couple of choices:

  • Update your dependencies to rely only on the ones deployed on central (may or may not be possible)
  • Follow the 3rd party uploading guide from Sonatype
  • Repack the dependencies within an module that have your project's groupId (org.ow2.something), so that it will be synched on central.



  • wagon-ssh in build/extensions is not required anymore (except for thoses producing a maven site with scp).
  • Use the ow2-release release profile if you want to add specific release behavior
  • Update your /.m2/settings.xml to use <password> instead of (or in addition to) <privateKey> for the ow2.releases and ow2.snapshots servers.


This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 6.4.4 - Documentation
Powered by XWiki Hosted by Xsalto Free PageRank Checker Creative Commons 2.0 license Legal Notice