John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 125 posts at DZone. You can read more from them at their website. View Full User Profile

A Tale of Two Repository Managers: Nexus and Artifactory Compared and Contrasted

  • submit to reddit

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.

Artifact searching

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.

Repository Maintenance

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,, 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)



Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Yoav Landman replied on Mon, 2010/01/04 - 6:08am

As you mentioned, since your comparison is focused on the enterprise feature, I am surprised that while you did use a version of Nexus Pro, you didn't use Artifactory's enterprise features (Artifactory Power Pack). We would have been happy to offer you a trial, as we give it away for free to open source users upon request.
As a result, I think some of the points you raise are lacking information, so it worth clearing them up:

Searches and promotion – you mention this as one of the strong points of Nexus, but this is one point where we received completely opposite feedback from enterprise users that tried both. The searches in Artifactory, combined with searchable properties, are what are being promoted and overall artifacts management is a different aspect. Instead of dynamically creating repositories (identified by a cryptic IP address/timestamp combo), deployed artifacts themselves are identified during deployment. Then you can find them, manipulate them (e.g. remove sources), promote them to a different repository, or export them to disk as one unit. You can even promote results to multiple repositories by copying (which is a simple operation in Artifactory).

The flexibility to combine and refine search results, together with permissions management and the ability to do something useful with the results is what makes the difference.

In Nexus you can search, but once you find some results you cannot do much with them, except view them. Therefore, I can see how you would assume that searching provides some degree of promotion; however, I strongly suggest that you try it.

While contrasting search capabilities, it is also important to mention that Artifactory's class/jar resource searches actually show you the classes found, unlike Nexus which only gives you a yes/no indication for jars containing your search. A user can also confine searches to specific repositories while searching.
Artifactory can also search inside Ivy module files (e.g. check where an Ivy dependency is used) and has unique Ivy and Gradle support.

Speed – there were actually reports of opposite results, with more substantial benchmark differences - Artifactory faster by >40%!, see: (the 'performance' section). Artifactory offers eager fetching for jars (once a POM is requested) and a high degree of caching, which makes a big difference in speed. This may also be one reason for the memory consumption differences: and in an enterprise environment, which is the environment you are covering, it is typically negligible.

Security – Artifactory has offered LDAP authentication with tight UI integration in OSS since the beginning. Version 2.1.4 (to be released in a couple of weeks) includes LDAP group support with more flexible mapping options than what Nexus currently offers and high caching (thanks to Spring Security). Artifactory also has Kerberos and native NTLM integration (with HTTPd) as an add-on.

Site hosting – Artifactory is a full Web Start/Java FX repository for hosting your apps in a secure way; offering central dynamic artifact signing and href rewriting. Again, this is part of the Artifactory Add-ons Power Pack, so I can understand how you missed this.

Maintenance – Artifactory has a very proactive default approach toward keeping repositories healthy. Repository reference cleanup is one example, and you can also block bad POMs (ones that are not parsed successfully by Maven, even if their checksum is correct—which is not uncommon). Another key feature of Artifactory concerns remote repository maintenance – you can import (or share via REST) the up-to-date definitions of the most common remote repositories, which makes the configuration error-free (spring, jboss,, etcetera). The ability to nest reusable groups of repository definitions is also a very powerful feature in Artifactory that doesn't exist in Nexus and makes repository management much easier.

One very important point that is missing in your comparison is Artifactory's integration with Hudson, which gives you full traceability from your builds to Artifactory and back, including seeing all artifacts produced with their dependencies, and the build environment information.

Thanks for writing this up, you are welcome to give a try to the Artifactory Add-ons Power Pack so that you can contrast it with the competing enterprise version.

We at JFrog will be happy to assist you.

(Also posted as a reply to the original blog entry)

Jessica-aileen Alten replied on Mon, 2010/01/04 - 12:35pm

The killer criterion for us was NTLM support. We have a corporate firewall and the proxy is configured to support only NTLM authentication, other authentication schemes are not allowed. Artifactory in its current version supports NTLM for this purpose, Nexus does not. So there was no real choice which repository manager we could use.

Shlomi Ben-haim replied on Mon, 2010/01/04 - 11:11am

Regarding Frederic last point - Artifactory's integration with Hudson - read more at the blog posted today at DZone: Empower Hudson with Artifactory - Track and Replay Your Build Artifacts

Brian Fox replied on Tue, 2010/01/05 - 9:12am

Regarding the performance gained by eager fetching, we evaluated eager fetching of JARs in early Nexus versions but decided to rank it low on our priority list for a couple of reasons:

1) It only benefits the first user requesting a set of artifacts. Typically the bottleneck is the external bandwidth and thus if the first user needs to download 25mb of jars, the order of the requests would only marginally affect the overall download time. However, if you're copying from another system on a high speed LAN (as you would likely use for benchmarks to control variation in network congestion) then the network wouldn't be the bottleneck and things would in fact test out faster.  

2) Maven makes requests for POMs during the resolution process that may ultimately be evicted from the graph.   Fetching these jars is potentially wasteful and could result in build slowdown as valid requests have to contend with bandwidth from pre-fetched JARs which will not be used. Maybe that's not an issue if you process it as a background process, but if that's the case, I wonder how often the eager fetching is requesting JARs before Maven does.

3) Recent versions of Maven are able to make parallel requests for artifacts, and are pretty effective at saturating the available network when needed, I would imagine this would cause some interactions with pre-fetching.

In short, I'm sure certain benchmarks in a completely clean system proxying a lan may run faster, but I would expect real world performance to be "typically negligible." Therefore in our view, the risk of complexity for the reward of small gains didn't pan out, but hey that's where choice for the user is better, I think it's just important to have perspective on the gains in real scenarios. 

Regarding the POM cleanup implementation, I also have pretty serious concerns about the implications of rewriting poms (not to mention the implied subtext of that blog title). I won't go into the details here but I would classify this also in the low upside, high downside category.

Regarding the importing and exporting of the repository configuration, this seems like a moot point when you have a full REST API. In Nexus, everything is done over REST, so that means you can import and export all the configuration, not just the repository config via wget if you feel like it.

In addition to the REST, Nexus supports the repository-metadata.xml standard used on Maven Central, where key information about a repository is available right inside the repo. This means that if so configured, anyone can discover the canonical urls for proxies, other known mirrors, what repos are contained by a group, and the release and snapshot type. This has been supported by Nexus since 1.3. Take a look here for a few examples of this metadata:

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.