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:
|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.|
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:
Nexus & Artifactory both offer OSS/free and Pro versions of their repository manager with additional features in pro.
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.