In “A Tale of Two Repository Managers” John Smart compares Nexus to Artifactory, and covers some of the more well known features like Staging and Security. I wanted to emphasize a few more of the other features that are often overlooked.
Most of our users download the tool, install it, and use the most straightforward features: simple proxy repositories, hosted repositories, and repository groups. We’ve gone out of the way to make Nexus intuitive, but I often wonder if enough people know about some of the features offered as part of the base project. Here are some of the features I would have highlighted in any comparison.
Mirrors / Repository Metadata Standards
We manage the Central Maven repository: a free public resource used by millions of developers every single day. This is a big part of what we do on a daily basis, and so we are acutely aware of the bandwidth being consumed serving the canonical, central repository to all the Maven, Ant, and Ivy users out there. Nexus is the only repository manager that is able to deal with mirrors in a true “mirror” fashion. Using the repository-metadata.xml if it exists, or by manual entry otherwise, Nexus is able to discover known mirrors of a repository. So when configured, Nexus is able to use a mirror that may be geographically closer to retrieve artifacts, while still falling back to the canonical repo if artifacts are missing and/or to validate checksums and pgp signatures. (http://www.sonatype.com/people/2009/03/new-feature-in-nexus-13-mirror-support/) This can greatly improve proxy performance without any of the downsides associated with using a mirror that could be slightly stale. No other repository manager currently does this.
In the searching arena, Nexus also supports the OpenSearch standard, allowing searching to occur directly from the search box in your browser (http://www.sonatype.com/people/2009/06/demonstration-of-nexus-opensearch-integration/) If you use Firefox, how often do you load up “http://www.google.com” to perform a search? It is a good chance that you use the search box that is integrated into your browser. This same search box can also be configured to search a Nexus instance. No other repository manager offers Open Search integration.
The Nexus Indexer format is the standard that all repository managers and IDE integrations use to fetch information about the contents of a remote repository. So while it’s true that the search in Nexus isn’t as fully featured as we would like, we have spent the time instead focusing on interoperability at the index level. The standard has been updated to break the dependency on Lucene 2.3, and to support incremental index downloads. As it stands today, Nexus is the only repository manager that can produce (not just proxy) indexes that are compatible with all the Maven IDE plugins and other repository managers. We find that most users would rather do the searching within their IDE and so we are empowering those users directly via the index integration. That’s not to say we don’t have some revolutionary things up our sleeve in the Nexus Search, but I’ll save that for another forum
All repository managers use the repository index standard that is set by the Nexus Indexer. All repository managers benefit from the time Sonatype has invested both in the Maven project itself, the development of an open source Nexus Indexer, and our continued efforts to reduce the bandwidth burden on Central as it serves an updated repository index to a world of developers using tools that interoperate with the formats we helped design.
Nexus is designed to be repository layout agnostic, while “Artifactory is a Maven 2 only repository manager by design.” Although we got some things wrong internally in the initial Nexus releases, things have been markedly improved. Nexus is able to support Maven1, Maven2, Eclipse P2, Eclipse Update Site, OBR, and most recently RubyGems. In many cases, these formats can be converted on the fly from one to the other. For example, you can expose an OSGI Bundle Repository containing every bundle in a Maven 2 repo (yes, even Central) in just a few clicks. If you work in an environment with multiple repository standards, Nexus is your choice. No other repository manager even comes close, our core engine with layout agnostic and we’re building a tool that will serve as a virtual “Tower of Babble”, converting between repository formats once thought incompatible.
Eclipse Distribution Management
One of the most overlooked features of Nexus Pro is the ability to proxy and aggregate Eclipse P2 and Eclipse Update sites. That means that all the benefits you gain by proxying and aggregating Maven repos are directly applicable to your Eclipse IDE users: Bandwidth savings, Time savings, single url management, etc. If you would like to understand more of those benefits, John Smart did a great job of enumerating them here: http://today.java.net/article/2010/01/04/maven-repository-managers-enterprise
Extensibility: Plugin API and REST Services
Nexus has a plugin model and associated maven-archetype to make it easy to extend. Users are already adding new features like security realms, repository types and new UI capabilities. If you take time to understand the architecture of Nexus, you’ll see that much of the functionality is implemented as a plugin. Plugins can affect the request lifecycle in Nexus, they can define new repository types, and add new capabilities to the underlying platform. Plugins can also customize the user interface and add new REST services.
Everything the Nexus web interface does is the result of some interaction with a REST service which you can access with your own custom Nexus plugins or user interface. If you have an idea for a novel approach to using Nexus or if you want to build your own custom administrative scripts that automate certain tasks, you can do so without having to deal with user interface issues. Nexus is the only repository manager that is built on a foundation of open REST services. Our REST services are not just an afterthought, a feature to list in a feature matrix. The REST services \*are\* Nexus, and you can take these core REST services and create novel tools and interfaces.
We were joking the other day that we’ve made Nexus so extensible, you could easily modify it to support the distribution of digital media. You could even use the metadata search feature to capture, index, and track your iTunes library with a custom repository type. While the discussion was facetious, the conclusion is accurate. We’ve been focused on using Nexus to develop solid, enterprise-class tools to manage binary artifacts and the metadata they are associated with. *You could use Nexus to keep track of just about anything.*
In short, Nexus is more than just a Maven repository manager. It’s part of a much larger ecosystem of tools that work together with defined standards that go from the command line build, to the CI system, the IDE and to production roll out. Nexus is developed and maintained by many of the leaders in the Maven arena, is backed by full time QA and support staff, and has a full length free book available for printing at cost.
The team that develops Nexus is also concerned with much more than a repository manager. The decisions we make about product features and direction are influenced by progress on the various open source projects that we participate in. Sonatype does more than just talk about repository managers. Through our work in the open source community, we are participating in open communities, and giving back as much as we can to the communities that support us. In addition to working on Nexus 1.4 over the past year, our engineers have served as release managers for new versions of Maven, and they have been working round-the-clock to get projects like Maven 3, the newer polyglot extensions to Maven, and Maven shell out and available for everyone to use.