Release history
Nexus descended from Proximity, which was the first MRM available. It was updated architecturally to be lighter and faster using the lessons learned from Proximity. Nexus also has the most active release cycle with Major releases every 6 weeks and minor releases much more frequently.

License

Apache License 2.0

Apache License 2.0

GNU General Public License 3.0

Deployment

Standalone

Embedded Jetty. JSW launch scripts - runs as a service on windows and unix

Jetty - runs as a serice on windows and unix. Complete script for installation as a service on unix, including user creation, permission settings and service config.
Tomcat - Complete script for installing a standalone Tomcat service on unix.
(optionally use the ARTIFACTORY_HOME variable)

Embedded Jetty. JSW launch scripts - runs as a service on windows and unix.

War

"Drop the War" - deploy into any servlet container with zero configuration.

RSS Feeds and UI viewer for bad checksums and artifacts with bad poms.
Bad poms are allowed through by default because many times Maven can still use them. We don't believe that simply inserting a repo manager should cause things to suddenly fail from Central. The repo man should for the most part be transparent by default.

Repository Statistics

Per repository or as a comparison among multiple repositories

RSS Feeds for New Artifacts

RSS feeds available both for new artifacts in the repository and for newly deployed/discovered versions of a specific artifact

Which is intentional because Maven doesn't actually need the full WebDav protocol. Since Nexus handles the data on disk, the http PUT is all that is needed. The standard lightweight http wagon can be used for deployment. Most of the Java implementations for the server side are non-compliant. Nexus goes for simplicity and performance.

No Wagon Extension Required (works with lightweight-http)

Deploy Artifacts via UI

Including snapshots and ability to auto-generate poms

can auto-generate poms.Accepts multiple files in one operation to accept classified/attached artifacts.

Manual deploying of SNAPSHOTs is not allowed as this is bad practice. 3rd party SNAPSHOTS should get converted to an internal release version so you can reliably use them in your builds.

Deploy Artifact Bundles (multiple artifacts in one go)

in future plans

Import local repositories

Import repositories and separate RELASE and SNAPSHOT artifacts

Releases and Snapshots should be kept in separate repositories. The import tools can separate these artifacts for you into discrete repositories.

Centrally controlled snapshot policy

Can choose between unique, non-unique or respect deployer's settings

Respect deployer's settings (from the pom)
Nexus doesn't mess with your files. What you deploy is what you store.(see next entry)

API to retrieve lastest SNAPSHOT based on coordinates

This API is available regardless of the deployer settings. This means it's still able to maintain timestamped snapshots and provide simple static links that can be used to retrieve the latest one.

via Jsecurity + ExtJs user console. Full role based with the ability to specify permissions based on the path of the artifact (group/artifact/version) using regex if desired.

Support Prevention of Redeploy

in future plans

Control over who can populate caches

Fully featured procurement support included in the pro version. This allows absolute control over the artifacts allowed through based on the artifact and user.

Support Protection of Sources / javadoc etc

Using Ant-like simple to understand patterns + OOTB templates for common include/excludes

Using the regex to control the paths, it is possible to secure separately any artifacts you want. Comes configured with targets to specify sources, which would allow you for example to have jars be downloaded anonymously but not the sources, even though they are sitting in the same repository.