| A tale of two repository managers: Nexus and Artifactory compared and contrasted |
 |
 |
 |
| Monday, 04 January 2010 00:00 |
      
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 useBoth 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 searchingSearching 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.
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.
SecurityIf 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.
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 strategiesBuild 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.
Deploying Maven web sitesOne 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 MaintenanceBoth 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.
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:
Trackback(0)
Comments (6)
  written by John Ferguson Smart, January 04, 2010
Thanks for taking the time to provide all these details, Yoav, I appreciate the feedback. You're correct, I have not used the commercial edition of Artifactory, only read about it, so my understanding of the Artifactory Power Pack features is obviously less thoroughthan that of Nexus Pro. I'd be happy to try out the Power Pack to see how it compares in the field.
 written by Brian Fox, January 06, 2010
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 from 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: * http://repo1.maven.org/maven2/...tadata.xml * https://repository.apache.org/content/groups/snapshots-group/.meta/repository-metadata.xml
 written by Mackenzie, March 15, 2010
Pdf ebooks searching service can also be used for the search of printing production, which might be bought in internet shops.
written by Mackenzie, March 15, 2010
Pdf ebooks searching service can also be used for the search of printing production, which might be bought in internet shops.
 written by Oxy, September 15, 2010
I have used both nexus and artifactory extensively and these are proven facts.
You will kick yourself if you ever have to migrate servers for artifactory and have to migrate a database rather than just a directory structure. Enjoy your constant re-indexing and database compressions.
Write comment
|
Tags
TrackBack URI for this entry
Subscribe to this comment's feed
Learning Corner
Upcoming courses
Copyright © 2007 - 2012 Wakaleo Consulting
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 (http://blogs.jfrog.org/2009/11...g-and.html), 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 (http://wiki.jfrog.org/confluen...g+with+Ivy) and Gradle (http://wiki.jfrog.org/confluen...ith+Gradle) support.
Speed – there were actually reports of opposite results, with more substantial benchmark differences - Artifactory faster by >40%!, see: http://java.dzone.com/articles...ager-nexus (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 (http://blogs.jfrog.org/2009/05...x-pom.html) 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, java.net, 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 (http://wiki.jfrog.org/confluen...ntegration), 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.