IMPORTANT MESSAGE (applicable May 2013 onwards):

This blog post was made when I worked for Specsavers. It has only been kept for archive purposes. I will not enter into discussions around maven artifact repositories nowadays. Please also bear in mind that some reasons listed below were specific to the Specsavers business and not for general application. There may of been business priorities that determined or skewed the selection process beforehand, and I would strongly advise not basing a sole decision on the below, but using the facts provided and your own research to come to your own fully informed decision. I now currently have no affiliation to Sonatype, JFrog or the Apache Software Foundation. Make of this what you will


In the team I work for, we support up to 200-300 developers at any one time. We currently use Apache Archiva. This has served us well for a number of years, but due to various ongoing maintenance issues (many not related to Archiva itself), we decided to research the possibilities of switching to a newer repository system.

This task was assigned to myself, so let the work begin:


The first step in the journey was to identify requirements for our next tool. This was done as a team-exercise, and the main requirements identified are shared below. Some requirements have been removed due to company sensitive information, and the list and priorities are ones we define unique to ourselves, so may not be applicable to others:

Priority Requirement
H Import existing artifacts from Archiva.
H Effective archiving and replication management & Disaster Recovery capabilities out of the box
H Support multiple hosted and proxy repositories, and should perform as a proper proxy rather than the way Archiva is at the moment.
H Be able to set different company specific Internal and Remote repository groups.
H Have ability to set proper permissions/authentication on the repos – ability of having LDAP/Active Directory integration and supporting User Roles matrix (ie. Different users, different roles and combinations)
H Deployable to & from existing build infrastructure with minimal impact to build activities (I.E simple settings.xml deployment in SVN)
H Good backup/replication mechanism.
H Ability for repository configurations to be config-managed either within the system with tracking down to changes and users or capability to integrate with any existing Config Managed tools (like subversion)
H Ability to set whitelist & blacklist patterns on contents retrieved from remote repositories
H Support standard binary types as artifacts – zip, tar, tar.gz, tar.bz2, rpm, jar, war, sar, ear, swf, swc, nar, exe, bat, dll, etc.
H Capability for custom log formats and logging levels.
H Capability for auto & manual purge of outdated repository contents, and ability to set time-line for expiry at repository level
H Installer should be available in standard formats with configurable options and log rotation capability.
H Capability to host the repository over SSL using company SSL certificate, over port 443
H Support for Maven Archetypes – search, indexing, managing custom archetypes, importing archetypes from remote repositories
H Seamless integration & capability to work with Jenkins CI & Cruisecontrol
L Support Repo browsing/searching for artifact retrieval.
L Manual artifact uploading.
M Hosted yum repositories & ability to sync/re-index
M Documentation to help Repository Users, Admins, and Managers
M Meaningful reports for Repository Users, Managers and Admins
M Capability of setting upload file size limits – good to have an association with user roles
M Capability to audit and generate reports & other relevant stats of the repository
M Capability to import/export repository definitions – in order to setup other Repository instances (ie. for Test, etc)
H Simple administration, Web administration of repositories and users vs config file hacking.
H Cost

Industry analysis:

I am not a Java dev, and probably never will be, so at the time of studying artifact repositories I had little idea of what the industry was doing as a whole. Off to google I went, and spent countless hours looking at various products, blogs, forums and case studies to identify what the industry is doing for their builds where their situation is similar to ours. The products I identified as possible candidates were:

  • Archiva
  • Artifactory
  • Nexus

Nexus & Artifactory both offer OSS/free and Pro versions of their repository manager with additional features in pro.

Trial run:

Following this, I installed trial instances of Nexus OSS + Pro (trial) & Artifactory OSS + Pro (trial). This was to allow comparison against the already installed instances of Archiva as well as to compare against the requirements listed above. I will cover the installation details of each in a later post when we come to the implementation phase.

In conjunction with this trial run, I researched into more detail what each product did at a lower level. What it could offer our company and how this relates to our main set requirements. I have to say, that one of the most useful articles in the entire process was a matrix comparison over at Codehaus. Some of the information was out of date, but overall it provides a good comparison between the products at a technical level.

Based on this, I was able to narrow down our search to Nexus Pro, Nexus OSS & Artifactory Pro

Unfortunately, Artifactory OSS was unable to provide enough features that suited our requirements or met with our various security policies.

Weighing up the values:

One procedure we use within our team when selecting new tools is a weighted spreadsheet comparing the products vs the requirements we have already set. This is based upon “Must Have, Should Have & Could Have” weightings which directly relate to our H,M & L requirement priorities. Each product was then given a grade by myself on 1-5 on how well I thought the product performed in that area, based upon my previous research and test installations. The table does not list every benefit of each product, but is targeted specifically towards our desired requirements as detailed above.

The results of this weighted comparison can be found at:


(This is because my wordpress theme did not like this large table one bit)

The competition was close, but clearly the Nexus products succeeds in the majority of our requirements (except costing).

Anyways this is a living post, and will be updated soon I’m sure, but for now gives a good overview of where we are at. When we start planning the implementation I shall document it in a further post.



6 Responses so far.

  1. olamy says:

    Why not continue with Apache Archiva. New versions series 1.4.x are really more performant with database removal and a new fresh ui ( http://olamy.blogspot.fr/2012/03/search-and-browse-with-archiva-new-ui.html )

  2. rob says:

    Yes, I agree the new UI in 1.4.x is a big improvement! – I do use Archiva for my own personal use. Although being in an enterprise environment, management can often shudder at the word “preview release”.

    However, one of the main items we need going forward is Active Directory integration. We had tried to integrate this previously, but this was unsuccessful.

    We are also very interested in many of the “additional” features that can be provided by Nexus, such as the Insight licence management features. Also based on the codehouse article linked, Nexus/artifactory do provide some features we may need in the future, such as OSGi/OBR integrations.

    We also are keen on the yum repo side of things, as one of our goals mid-term is to integrate yum repositories into our CI loop.

    Finally, being a corporate entity, we may be looking at enterprise level support, something with Sonatype have a very sound reputation for and which Artifactory can provide, but unfortunately Archiva has limitations in this area!

    But I do appreciate the feedback – as I said I am relatively new to the Build Engineering side of things, and learning new things every day :)

  3. Baruch says:

    Hi Rob,

    just send you an email with my 2 cents (well, according the size of the mail, more like my 200 bucks) :)
    If you find it useful, update to the post will be appreciated – it is found well by Google :)


    • Baruch says:

      Hi Rob!

      I bumped into the comparison of binary repositories in your blog. First of all – good job! Looks like you invested serious amount of time and effort. As you probably already figured out from my mail address and signature, I disagree on the outcome :D

      To be serious, I wouldn’t bother you (Nexus is a good product, and lots of people are pleased with it), but I noticed some inaccurate conclusions regarding Artifactory. I am sure it’s our fault in communicating some of our product features, but I took the liberty to contact you and try to fix the impression you are under. Here are some points in which, I believe, Artifactory do better than you graded:
      Backup: We have rock-solid automatic backup procedure, that does all the work for you. Artifactory can perform full and/or incremented backup to a directory of your choice in any selected time(s). Here are the details. Please also note that you can perform off-application backups, as described below in ‘DRP’ bullet.
      Replication: Frankly, comparing our powerful and flexible replication mechanism to Nexus’ experimental beta support of event-driven only replication looks like uneven contest (not in Nexus’ favor) ;) . I recently wrote a blog about replication, you might find it interesting. Here is the official documentation on checksum based push/pull replication.
      DRP: we support active/passive architecture both over NAT and by rsync for extremely good MTR (specially on NAT). Same procedures can also be used for backup.
      Permissions/Authentication from LDAP(AD) – we fully support LDAP integration for users and groups (including auto-adding to groups in Artifactory based on LDAP groups, etc.) More so, Artifactory has a unique feature of passing encrypted password over a wire (this is a critical feature when using your corporate password for binary repository).
      Support for Maven archetypes: We have full support for Maven archetypes (as for any another file types). They are fully indexed (including the contents of the jar), searchable and can be imported from remote repositories just as any other artifact.
      Ability to track and manage repository configurations: Repository configuration (as any other Artifactory configuration) is reflected in configuration file for that precise reason (for you to track, diff and manage them). We also keep any number of previous editions of the configuration file for management and backup purposes. Here is the documentation on Artifactory configuration files.
      Documentation – You probably found our wiki. Except of it, we are trying to blog about Artifactory’s latest and most interesting features and occasionally record screen-casts to demonstrate features in action. Our mailing list is known as active and very responsive a lot of users (both open-source and pro) use it as good source of information. We also willingly help with any question users have in social networks, like Twitter, Facebook and Google+.
      Whitelist and backlist patterns – Artifactory has full support for include/exclude patterns on any repository (not only on remote, but also on local and virtual). We also support those patterns in permission target security definitions to allow whitelisting/backlisting for users/groups. We consider that functionality so basic, it exists in our OSS version from day one.
      Custom log formats and levels – we are using logback as our logging framework. That means that you have full control on logging formats and levels (just use the java packages to control the levels). Just edit the logback.xml and the logging will be automatically reconfigured.
      Integration with build server: Again we are very proud with our build server integration feature, and believe that we are way ahead of our competitors in that field, specially when it comes to Jenkins CI. Our Jenkins Artifactory plugin not only fixes Maven deploy flaw in multi-module projects (deploying after each module build is so wrong) but also gathers bill-of-materials (BOM) with full build information, allowing deep two-way integration between your binary repository and build server. This integration gives you full drill down from the build level to specific artifacts and dependencies, environment variables, build-level searches, bi-directional linking, and much, much more. Another superb feature of that plugin is the release management functionality, which gives you the ability to establish release procedure and customize it to your company business requirements in automated and trusty way.
      All those features are available for the market leading build servers – Jenkins, Bamboo and TeamCity. For all the rest (inc. CruiseControl that you mentioned) we provide the same support once you use Gradle, Ivy or Maven. I’d speculate you are using Maven, in that case you can enjoy all the benefits of build server integration with any build server using our Maven Injector, which collects the build info BOM directly from Maven.
      Hosted Yum repository with re-sync and re-index: Again, I am a bit surprised Nexus rated higher than we are, since our indexing is immediate. What can be better than having up-to-date index without the need to re-index? No re-sync needed either – the metadata is calculated on the fly and always up to date. Some other goodies include running from platforms without yum support (like Debian or Solaris), permissions awareness, etc. Basically, since Artifactory is not Maven-oriented tool, all ‘special’ repositories (like Yum) aren’t special for us, and the support is as full and as good as the ‘regular’ Maven jars repositories.
      Capability of setting upload file size limits: I am a bit unsure what you meant here, but we have a limit on size of artifacts uploaded from the UI. Since Nexus graded so high in that feature I tried to find how they do it, and didn’t find it. Can you please point me to what you meant? Thanks. I’d speculate that you referring to the ability to limit the size of uploaded files by certain users/groups. If that’s the case, it can be easly achieved by a simple user plugin (very flexible and powerful way to extend Artifactory’s functionality). All that needed is “before storage” hook that will check the uploaded artifact size and the deployer user/group and return an error when needed. You can find some plugin examples in our GitHub and see how simple and straght-forward they are.
      Wow, lots of bullets. I hope that gives a bit more balanced view on how Artifactory compares to Nexus.

      Please contact me for any questions/clarifications. We will be more than welcome to help you evaluate Artifactory if you decide you want to give it a try.

  4. Baruch says:

    Hi Rob,

    no reply to my mail and/or comment?

Leave a Reply

Twitter updates

No public Twitter messages.