Re: Contrasting Artifactory and Nexus

I do not care too much about product comparisons coming from product vendors since they are usually biased and written with a single mindset of “how do I make my product look better”. Being labeled with an “I’m nonobjective” sticker from the start, I tend to take them with limited trust.

I recently came across a blog post from Brian Fox of Sonatype, which ships Nexus Pro, a competing product to Artifactory, trying to contrast the two products. We, at JFrog, actually like and thrive from this competition as it is giving us a lot of motivation and directions on how to become even better. However, the comparison done in this blog is actually not a very useful one. Not only it is written with the prime goal of looking for cons in Artifactory, but unfortunately (or, actually, fortunately for Artifactory) almost all points brought up range from plain wrong to just pure FUD.

Let’s look at each point at its turn:

1. Network: WebDAV vs. REST
The author suggests Artifactory uses WebDAV with Maven. This is plain wrong! I don’t know where this “fact” was taken from, but it is just not true – Artifactory exposes a pure HTTP/REST interface (GET/PUT) which is used by the HTTP wagon of Maven.
Maybe this poor assessment came from the fact that Artifactory also offers WebDAV clients support, but this is an extra feature, on top of HTTP/REST support.
So, assuming that Artifactory will be slower, like the author did (because they tried WebDAV in the past and found it slow) is completely irrelevant.
BTW, while we’re at it, we have found the Maven WebDAV wagon to perform much better with huge file deployments and to consume considerably less memory on the client side.

2. Storage: Relational Database vs. Filesystem
For some reason, the author is tossing away the robust architecture used by other, much more widely used, repositories, such as: SVN, YUM, APT-GET to name a few.
Magical tales about “re-healing” of lost metadata do not work when this metadata is not reproducible from pure file data (like file name and path). Metadata has to travel with the data as one unit. If I want to know who originally deployed an artifact, there is no way I can restore this piece of information from the file name.
There is more to it, like when you delete and artifact, Artifactory makes sure that both you deletion, the maven-metadata and the indexes are updated as one transaction – no need to schedule jobs or manually fix annoying inconsistencies that will break your build later on.
The Artifactory 2 storage is rock solid today, and we also fully support incremental backups (including incremental metadata). A disk error could make your complete storage become unreadable (at least without complex recovery efforts, LVM anyone?) and I would like to meet in person a CM who doesn’t take backups. Sorry, but saying that your data is at risk because you are using a database store is nothing but FUD.

3. Storage Size
This might be true and might be attributed to several reasons, like keeping richer indexes. Anyway, unless you are running on a 3 years old machine, then frankly, who cares? Really, would your criteria for selecting one product above the other would be because one uses a couple of few gigs less storage space? If yes, I suggest you check the hard drives available today on both server and consumer machines. Same goes for consuming>64MB of RAM (though we do run Artifactory with the default VM heap). Come on…

4. Nexus Doesn’t Interfere
By default, Artifactory takes a conservative approach towards repository pollution, and is trying to shield you from some of the chaos that is going around the Maven central repository, mainly with older legacy artifacts. Most of the wrong POM specifications can be found duplicated on repo1 under the correct coordinates, so Artifactory produces a meaningful error, urging you to correct your POM spec.
Anyway, this protection can be easily switched off by going to the artifactory.system.properties file and commenting out the line that says: artifactory.maven.suppressPomConsistencyChecks=true. So again, this is irrelevant.

Sure, the comparison made by the Sonatype blog is nonobjective. It is natural for a competitor and, of course, I wouldn’t expect it to mention pros about Artifactory like simplicity and excellent user experience, integrated UI driven LDAP integration that you don’t have to shell out $3,000 for, support for encrypting user passwords in settings.xml, find and remove legacy deployed modules across directories, single deployment for a bundle of artifacts, local repositories import, etc. But, this comparison is also irrelevant, since it relies on wrong or missing information and sometimes on pure FUD.

We do have a lot of appreciation to you at Sonatype for all your contribution around the Maven ecosystem. It’s also natural that you want to push your commercial product, but it is very unfortunate when you decide to promote your product by trying to make other products look bad. It’s also a shame, that instead of putting valuable time into developing new great features for Artifactory, I have to use this time for clearing up this kind of wrong information. There’s a whole community enjoying our efforts, so let’s give them good open source products and invest the time in productive directions.

Learn more about JFrog Artifactory vs Sonatype Nexus.