New to the Professional version is OSGI Bundle Repository support. Stuart summed it up nicely in his detailed post:
…but how does this relate to Nexus Professional? Well with Nexus Pro 1.3.5 you will be able to:
- dynamically generate OBR metadata for your existing repositories
- proxy and cache remote OBRs, including both metadata and bundles
- host local OBRs and deploy bundles into them using the UI or Maven
- group all of the above types of OBRs into a single merged OBR
- apply CRUD privileges to control access to particular bundles
Basically the same things you can do with Maven and P2 repositories you can now do with OBR!
Other than the new OBR plugin, this release was primarily to fix some bugs that cropped up since the 1.3.4 release a few weeks ago. We deem these fixes important and recommend everyone upgrade to the latest release.
We run 3 Nexus instances at Sonatype (repository.sonatype.org, oss.sonatype.org, osgi.sonatype.org) and one at Apache (repository.apache.org). This puts us in a unique position to identify and fix issues before they become an issue for our users and the orgainzations that have started to rely on Nexus for software distribution.
We have about 40 repositories in our r.s.o instance and we’ve been running with just 256mb of ram, intentionally constrained to keep an eye on any memory issues. In this case it worked as we started having oom exceptions (Nexus-2229). After some investigation, we determined that our configuration of ehcache was not optimal for large instances. We use ehcache to maintain the negative caching results for artifact lookups. The trouble is that there was a limit per repository but each repo had it’s own cache. This meant the total memory footprint of the caching was unconstrained and grew linearly with each new repository. In 1.3.5 we reduced the count and in 1.4 we’ve redesigned the caching to share a single cache across all the repositories. This way the caching can be optimized for the size of your instance, but out of the box the memory consumption is bounded.
On the Apache instance, we discovered that the snapshot remover didn’t like projects using non-unique snapshots. Generally when you have a repository manager that is able to clean your old snapshots, there’s little point in using non-unique (not timestamped) snapshots. Regardless, Nexus should support all valid Maven use cases so this was included in 1.3.5.
The most potentially serious condition we discovered (Nexus-2121)was that the Evict unused proxy artifacts task would evict items from a hosted repository if configured to run on one (or if all repositories was selected). When this was uncovered, we notified the user list of the problem to avoid any user impact. Fortunately, Nexus never deletes any files directly, and delete operation simply moves it to a trash folder, which is manually purged (or scheduled). That means no data was lost and the problem is now fixed in 1.3.5.