Sonatype Nexus Repository 3.48.0 Release Notes
Highlights in This Release |
|---|
Content Replication In this release, we introduce a simpler, more straightforward way to make your artifacts readily available across distributed teams: content replication. With content replication, you can manage what binaries are copied from one instance and pre-emptively pulled via HTTP to other instances. Read more below Upgrade Impacts for Those Using PostgreSQL Databases After upgrading to 3.48.0, those using an H2 or PostgreSQL database will need to run a task for each existing Apt, Helm, and Yum repository in order to rebuild their metadata. Read more below |
What's New and Noteworthy in This Release?
See the complete release notes for everything included in this release.
New and Improved Content Replication PRO
This feature only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.
In 3.34.0, we introduced our first replication feature, which used a manually run replicator tool to copy binaries from one blob store to another. We've learned a lot since our initial replication release, and we've gratefully received and listened to your feedback.
In this release, we introduce a simpler, more straightforward way to make your artifacts readily available across distributed teams: content replication
With content replication, you can manage what binaries are copied from one instance and pre-emptively pulled via HTTP to other instances. The following diagram illustrates the content replication process, which is also described below:
- New assets are published to the Sonatype Nexus Repository source instance
- The replication task runs on the target instance on a schedule (each minute) to identify new assets
- The replication task issues proxy requests for each new asset to replicate them to the target instance
- Users on the target instance now have access to newly added artifacts on the target instance
There are multiple ways you can use content replication, including having multiple targets proxying one source, bi-directional content replication, or replicating a subset of content. You can learn more about these use cases and how to configure them in Content Replication Use Cases and Scenarios.
What's Changed?
Content replication removes the requirement for manually running a separate replicator tool. It is far easier to configure and automatically runs every minute (or on your desired schedule as configured).
Content replication also has a shorter list of prerequisites and supports more formats!
The following table shows the formats that could use legacy replication vs. those that can use content replication.
| Sonatype Nexus Repository Formats | Legacy Replication | Content Replication NEW IN 3.48.0 |
|---|---|---|
| Apt |  |  |
| Docker | | |
| Helm | | |
| Maven | | |
| npm | | |
| NuGet v3 | | |
| R | | |
| Raw | | |
| RubyGems | | |
Neither content replication nor legacy replication support Cocoapods, Conan, Conda, Git LFS, Go, p2, PyPI, or Yum formats
Is Content Replication Appropriate for Me?
We cover this fully in our content replication documentation; however, if you're looking to reduce latency and make your content available to distributed teams quickly and efficiently, then we designed content replication with you in mind. Follow the simple content replication setup procedure to get started today!
What Will Happen to Legacy Replication?
While help documentation for legacy replication remains available, it will be unavailable for general use, and we will eventually remove it. Reach out to your CSE if you are still using legacy replication and would like to continue using it.
Improved NuGet v2 Performance on PostgreSQL PRO
In this release, we made pagination performance improvements for NuGet v2 repositories on deployments using a PostgreSQL database. After upgrading to 3.48.0, users can expect pagination in NuGet v2 repositories to improve so that retrieving a page takes only milliseconds rather than multiple seconds.
Notable Upgrade Impacts
After upgrading to 3.48.0, those using an H2 or PostgreSQL database will need to run a task for each existing Apt, Helm, and Yum repository in order to rebuild their metadata:
- Apt - Rebuild Apt metadata for each Apt repository
- Helm - Rebuild Helm metadata for each Helm repository
- Repair - Rebuild Yum repository metadata (repodata) for each Yum repository
Bug Fixes
| Ticket Number | Description |
|---|---|
| NEXUS-36573 | Creating new repositories no longer triggers a complete Helm index rebuild for those using OrientDB. |
Improved performance of NuGet v2 FindPackagesById() requests for NuGet repositories using many versions. | |
| NEXUS-37617 | Fixed an issue that was causing UI latency when loading welcome page in some circumstances. |