Nexus Migration Guide
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 theanymore.
Disengagement will be done in 3 phases:
- Repository will be read only
- Projects will no more be able to deploy artifacts to and repository
- 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
- 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 (component ) 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.
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(GAV : org.ow:ow2).
<!-- ... -->
All released artifacts must be signed with a GPG key.
Release Managers must read the. They should not forget to distribute their public key to key servers.
Theses rules applies to the parent POM of the staged artifacts (for a multi-module project).
Project POM must have the following elements:
No Releases Repositories
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.
- 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.