There are several Maven repository managers on the market, but the two most prominent and most powerful are without doubt Nexus and Artifactory. Both these products are open source, with commercial versions containing more advanced features. Both are fine products, with many similar features. In many cases, however, Nexus and Artifactory respond to similar user needs, but in quite different ways.
In this article, I will try to give a general picture of a few of the main distinguishing features of these two tools, from the point of view of how you might want to setup your enterprise repository in a real organization.
Installation and general use
Both Nexus and Artifactory are easy enough to install. Nexus does use a lot less memory (around five times less according to my unscientific trials). A full build for a medium-size project on my workstation ran roughly 15% faster with Nexus.
Searching for artifacts can come in handy from time to time. Nexus provides a simple, Google-like search interface for searching both your cached repositories and the remote repositories (you can actually configure whether you want a particular remote repository to be included in local searches). Nexus also supports Open Search, so you can integrate the Nexus search function directly into your browser (see below). The Nexus search feature also lets you search artifacts by other criteria, such as classname, GAV (group/artifact/version) or metadata.
Figure 1: The Nexus search in action.
Artifactory uses a different approach to searches. The search screen is quite detailed: as well as searching by keyword, classes, GAV, you can even search on Pom file contents using XPath. Searches however are limited to artifacts that are stored in the repository. This might be due to the fact that Artifactory documentation recommends using searches and metadata for build promotion strategies. You can search for metadata (called 'Properties in Artifactory') and save search templates in the commercial edition of Artifactory.
Figure 2: The Artifactory search screen.
If you work in a large organization, you probably don't want developers from other teams being able to deploy snapshots and releases for your project. Both Artifactory and Nexus have flexible flexible security models, build around users, user groups, and repository targets. With both, it is easy to limit the rights of a particular user or group to a particular part of a repository, for example, though the use of regular expressions in Nexus gives it more flexibility in this area. The Nexus model is more fine-grained and more powerful, but at the cost of a slightly more complicated user interface.
Figure 3: Configuring users and permissions in Artifactory.
Figure 4: Configuring users and permissions in Nexus.
Organizations often need to integrate with an LDAP repository. Artifactory comes with support for LDAP authentication out of the box, though this does not include advanced features such as mapping LDAP groups to Artifactory groups or permissions. The upcoming open source version of Nexus (1.4.2) comes with powerful integrated LDAP support, including authentication, mapping LDAP users directly to Nexus permissions, and mapping LDAP groups to Nexus roles. This sort of feature is highly prized by larger organisations with large existing LDAP repositories. The commercial edition (Nexus Pro) promises even more advanced LDAP features such as support for multiple LDAP servers and enhanced caching.
Build promotion strategies
Build promotion strategies basically involve moving artifacts from one repository to another depending on their stage in the build promotion process. You can implement such strategies manually, but a bit of automation can really make your life easier.
Artifactory supports build promotion to some extent in its commercial version, using a combination of repository metadata and a process of manually copying or moving groups of artifacts between repositories.
Build promotion is one of the areas that Nexus Pro really shines. You can set up a Staging profile, which intercepts certain artifacts (for example, release artifacts for a particular project) and places them in a special, dynamically-created repository. Once all the required artifacts are deployed, a build administrator can make these staged artifacts available for further testing (in a UAT environment, for example). Involved users can be notified when a build is staged and promoted, so that they can go to the relevant environment and run their own tests. When the tests are finished, the artifacts in the staging repository can be promoted to their final destination (for example, a special Production Releases repository). You can also associate rules with this promotion process, to check things like the validity of the pom file or the presence of javadocs in the artifacts. These rules are highly configurable: you can even use them to kick of an automated deployment process when the staging is done, for example.
Figure 5: Promoting a build to production in Nexus Pro.
Deploying Maven web sites
One other neat feature available in Nexus Pro is the ability to deploy Maven sites. This gives you a convenient central server where you can deploy and consult the Maven web site for each of your projects with a minimum of fuss and effort.
Both tools provide good support for repository maintenance, but with a very different feature set. Artifactory proposes to actively tidy up pom files that it downloads, by removing any declarations of remote repositories in them. It also lets you limit the number of snapshots per artifact for each repository. In Nexus, you can also schedule maintenance tasks such as deleting old snapshots, backing up configuration files and so on. You can also configure Nexus to delete all the snapshots for a particular artifact when it is release, which can save quite a bit of space for large projects.
Figure 6: Configuring scheduled maintenance tasks in Nexus.
So which repository manager should you choose?
This comparison is far from complete. Both Artifactory and Nexus are solid, feature-rich products, and the competition is good, as it keeps both product teams on their toes. My personal recommendation however goes to Nexus, as in my opinion it has better support for the requirements of larger organisations, and is nicer to work with in the context of build pipeline automation. Here are a few reasons why you might prefer Nexus:
- Nexus Pro has many powerful features, such as staging and procurement, well-suited to the needs of large organizations
- Nexus is rock-solid and extremely well battle-tested: is widely used on many very large-scale repositories (including http://oss.sonatype.org, http://repository.apache.org, http://nexus.codehaus.org and many other open source repositories)
- Nexus is superbly documented - a very well-written book (Repository Management with Nexus) is freely available online.
- User Interfaces are very much a matter of taste, but for me Nexus has very a clean, fast user interface with just the right amount of AJAX.
- Nexus Pro includes support for OSGi bundles (OBR) and Eclipse P2 repositories - very cool if you need that sort of thing.
- Lightweight and efficient (runs in only 28m)