This appendix walks you through the process of migrating an existing Archiva installation to a new Nexus installation.
Archiva uses the file system to store hosted repositories and proxied repositories, making migration from Archiva to Nexus very simple. The following sections outline the process for migrating existing Archiva repositories to a new Nexus instance.
Archiva Managed Repositories are the equivalent of Nexus Hosted repositories. To migrate a Managed Repository from Archiva to Nexus, do the following:
- Create a New Hosted Repository in Nexus.
- Copy the Contents of the Archiva Managed Repository to the Storage Directory of the newly-created Nexus Hosted Repository.
- Rebuild the Index for the New Nexus Hosted Repository.
The following example will walk through the process of migrating the
Archiva repository named
internal, to a new Nexus Hosted repository
named "internal". To view your managed repositories in Archiva, login
to Archiva as an administrative user and click on the Repositories
link in the left-hand navigation menu. Clicking on Repositories will
list all of your Archiva Managed repositories as shown in Figure 23.1, “Archiva Managed Repositories”.
To migrate this Managed repository to a Nexus Hosted repository, find the directory in which Archiva stores all of the repository components. To do this, click on the Edit link listed next to the name of the repository you want to migrate as shown in Figure 23.1, “Archiva Managed Repositories”. Clicking on Edit should load the form shown in Figure 23.2, “Editing an Archiva Managed Repository”.
Take note of the file path for Directory. The file path shown in Figure 23.2, “Editing an Archiva Managed Repository” is ./data/repositories/internal. If Archiva is installed in /usr/local/archiva-1.2.1, it should correspond to the directory /usr/local/archiva-1.2.1/data/repositories/internal. You will use this path later in this section to copy the contents of your old Archiva Managed Repository to your new Nexus Hosted Repository.
Next, create a new Nexus repository with the same identifier and Name as the old Archiva Managed Repository. To do this, log into Nexus as an administrative user, click on Repositories in the left-hand Nexus navigation menu, and then click on the Add drop-down as shown in Figure 23.3, “Creating a Nexus Hosted Repository”. Select "Hosted Repository" and then fill out the Repository ID and Repository Name to match the name of the old Archiva repository. If you are migrating a Snapshot repository, select a Repository Policy of Snapshot, and if you are migrating a Release repository select a Snapshot Policy of Release.
Now, you’ll need to copy the Archiva repository to the Nexus repository. You can do this by copying the contents of the Archiva repository directory to the Nexus repository storage directory. If we assume that Archiva is installed in /usr/local/archiva-1.2.1, Nexus is installed in /usr/local/nexus, and the Sonatype Work directory is /usr/local/sonatype-work. You can copy the contents of the Archiva managed repository to the new Nexus hosted repository by executing the following command:
$ cp -r /usr/local/archiva-1.2.1/data/repositories/internal/* \ /usr/local/sonatype-work/nexus/storage/internal/
If you are migrating to a Nexus instance on a different server, you can simply create an archive of the /usr/local/archiva-1.2.1/data/repositories/internal directory, copy it to the new server, and then decompress your repository archive in the appropriate directory.
Archiva stores components from proxied remote repositories in the same directory as components in a managed repository. If you have been proxying a remote repository, you might want to remove components that have been proxied from a remote repository. For example, if your organization uses a groupId of org.company for internal project, you can make sure to only copy the components under the corresponding org/company/.
Once the contents of the repository have been copied to the Nexus Hosted repository, you must rebuild the repository index as shown in Figure 23.4, “Rebuilding the Index of a Nexus Hosted Repository”. Right-clicking on the repository in the list of Nexus repositories will display the context menu shown in the following figure.
Once the migration is complete, you will be able to search and browse the contents of your newly migrated Nexus Hosted repository.
Archiva allows you to define remote repositories and repository connectors to proxy remote repositories and cache remote components from remote repositories in Archiva Managed Repositories. While Nexus also provides Proxy repositories, there is one major difference between Nexus and Archiva. Where Nexus maintains a separate local storage directory for each proxy repository, Archiva combines cached remote components into a single file system with the contents of a managed repository. In other words, there is no good way to transfer an existing local cache of components between Archiva and Nexus without manually manipulating the contents of Archiva’s Managed Repository directory.
To recreate an Archiva repository connector in Nexus as a Proxy repository and to preserve the local cache of components from this repository. You’ll need to create a Proxy repository in Nexus, copy the contents of the existing proxy repository to the Nexus storage location for you new Proxy repository, and then rebuild the metadata of your new Nexus Proxy repository.
First step is to take a look at the Remote Repositories in your Archiva installation. Log in as an administrative user and then click on Repositories under the Administration menu in the left-hand Archiva navigation menu. Once you’ve clicked this link and loaded the list of repositories, scroll to the bottom of the page to see the list of remote repositories as shown in Figure 23.5, “Browsing Archiva Remote Repositories”.
Defining a proxy repository in Archiva involves associating one of the remote repositories defined in Figure 23.5, “Browsing Archiva Remote Repositories” with one of the Managed Repositories defined in Figure 23.1, “Archiva Managed Repositories”. Once you do this, requests for components from the managed repository will also query the remote repository. If a component is found in the remote repository, it will be retrieved and stored in the managed repository’s storage directory. To see a list of proxy connectors and the managed repositories with which they are associated, click on Proxy Connectors in the left-hand Archiva menu and you will see a list similar to that shown in Figure 23.6, “Archiva Proxy Connectors”.
Click on the edit icon (or pencil) next to second Proxy Connector listed in Figure 23.6, “Archiva Proxy Connectors”, to load the settings form for this proxy connector shown in Figure 23.7, “Archiva Proxy Connector Settings”. You should use the settings for this proxy connect to configure your new Nexus Proxy repository.
To create a Proxy repository that will correspond to the Proxy Connector in Archiva, log into Nexus as an administrative user, and click on Repositories in the left-hand Nexus menu. Once you can see a list of Nexus repositories, click on Add… and select Proxy Repository from the drop-down of repository types. In the New Proxy Repository form (shown in Figure 23.8, “Creating a Nexus Proxy Repository”) populate the repository ID, repository Name, and use the remote URL that was displayed in Figure 23.5, “Browsing Archiva Remote Repositories”. You will need to create a remote repository for every proxy connector that was defined in Archiva.
To expose this new Proxy repository in a Repository Group, create a new Nexus Repository group or select an existing group by clicking on Repositories in the left-hand Nexus menu. Click on a repository group and then select the Configuration tab to display the form shown in Figure 23.9, “Adding a Proxy Repository to a Repository Group”. In the Configuration tab you will see a list of Order Group Repositories and Available Repositories. Click and drag your new Nexus Proxy repository to the list of Ordered Group Repositories, and click Save.
Next, you will need to define repository groups that will tell Nexus to only locate certain components in the newly created proxy repository. In , Archiva defined three patterns that were used to filter components available from the proxy connector. These three patterns were "javax/", "com/sun/", and "org/jvnet/**". To recreate this behavior in Nexus, define three Routes which will be applied to the group you configured in Figure 23.9, “Adding a Proxy Repository to a Repository Group”. To create a route, log in as an administrative user, and click on Routes under the Administration menu in the left-hand Nexus menu. Click on Add.. and add three inclusive routes that will apply to the repository group you configured in Figure 23.9, “Adding a Proxy Repository to a Repository Group”.
artifactory]] === Migrating from Artifactory
This appendix provides a guideline for migrating a Maven repository from Artifactory to Nexus.
Typically migrating from Artifactory revolves around migrating hosted repositories only, since any proxy repositories configured in Artifactory can just be set up with the same configuration in Nexus, and all data will be retrieved from the upstream repositories again.
Hosted repositories on the other hand have to be migrated. The best practice for migration is to use the import/export feature of Artifactory and migrate one hosted repository after another. Please consult the Artifactory documentation for step-by-step instructions on how to export a repository.
After the export, you have to create a hosted repository in Nexus
e.g., with the name
old-releases as documented in
Section 4.4, “Adding a New Repository”. This will create a folder in
Now you are ready to take the exported repository and copy it into the newly created storage folder.
Going back to the Nexus user interface, navigate to the repository administration and select the Browse Storage panel. Right-click on the root folder of the repository and select Rebuild Metadata first. and as a second step select Update Index. Once these tasks are completed, the migrated repository is ready to be used.
After these task are completed, you will probably want to add the migrated repository to the Public Repositories group or any other group in which you want the migrated repository content to be available.
If you want to ensure that the repository does not get any further content added, you can set the Deployment Policy to Read Only in the Access Settings of the repository Configuration panel.