Repositories have become an essential part of software development nowadays. Great importance are being given to the use of repositories, and because of this, a lot of open source tools for managing them are now available. As an Archiva developer, I wanted to compare the features that each has (even if I may be biased).

Archiva

Archiva is a build artifact repository manager for use with build tools such as Maven, Continuum and Ant. It can act as a nearby (proxy) cache of popular global repositories. It has other features such as repository purge (of snapshots), repository search and browse, securing repositories, identifying unknown artifacts and reporting of repository problems. The version I’ve used here is 1.0-beta-3. Below are the features of Archiva:

• Easy to run. Just unpack the binaries, cd to /bin/linux-x86-32 and execute ‘run.sh console’ (the last two steps depends on the OS you’re using). You could also opt to just execute ‘plexus.sh’ or ‘plexus.bat’ in /bin.

• Proxy and cache. Allows hosting of private repositories (managed) and proxying of other repositories (remote). Proxying is one of the major features of Archiva. It makes use of the concept of proxy connectors. Proxy connectors are configuration for connecting a managed repository to proxy a remote repository. Archiva allows proxy configuration of blacklist and whitelist patterns as well as download policies.

• Repository configuration. Configuration is stored in the archiva.xml file. The configuration can be edited via the webapp. Items which are configurable are: repositories, repository scanning, database scanning, proxy connectors, network proxies and consumers. Remote and managed (local) repositories have separate configurations so it is easy to identify one from the other. Repository scanning, where indexing and repository purging happens, can be executed per repository. This can be scheduled or explicitly triggered in the Configuration page.

• Repository purge. If enabled, Archiva performs automatic removal or deletion of old snapshots in the repositories during repository scanning. You can choose from these 2 criteria: either by the number of days old or by retention count. Deletion of released snapshots can also be enabled by checking the ‘Delete Released Snaphots’ checkbox in the repository configuration page.

• Reports. Archiva uses Jasper Reports for reporting. The reporting is currently limited to a report of defective or problematic artifacts in the repositories. You can configure the number of rows per page to be displayed in the report.

• Search and repository browse. You can search artifacts in Archiva as well as browse the repository. The bad side about this is there is no separation among the different repositories. All the artifacts are in the Browse page. The good side is that the artifact info is very informative and useful, which I think definitely compensates the bad side. You could browse each repository anyway via the webdav. A webdav url is available in the repository configuration page which you can just click and be able to browse that repo in the web browser. The artifacts can also be downloaded, though it cannot be deleted via the Repository Browse.

• Finding artifacts. You can find artifacts in the repository via the checksums. You can either input the checksum manually OR browse for the unknown artifact itself and Archiva will calculate its checksum and search for it in the repo.

• User interface. Archiva uses Webwork for the user interface. The UI is simple and organized, though load time of pages could still be improved.

• Deploying artifacts. Archiva has support for artifact deployment via webdav.

• Source code. The source code is designed very well. The modules are properly organized into components, which makes it easy to plug new features as well as to disable one. Below is Archiva’s source structure:
  • archiva-base - contains the core modules of Archiva, which are the configuration, model, converters, repositories, indexing, proxies, policies and utility modules.
  • archiva-cli
  • archiva-database - the module which deals with the database processes.
  • archiva-reporting - the module for Archiva’s reporting mechanism.
  • archiva-scheduled - the module which handles the scheduling and execution of specific tasks.
  • archiva-site - contains the information for Archiva’s web site.
  • archiva-web - contains the modules for the web component.

Artifactory

According to its website, Artifactory is a Maven 2 enterprise repository which offers advanced proxying, caching and security facilities to provide for a robust, reproducible and independent build environment using Maven 2. The version I used for this comparison is 1.2.2. Below are the features of Artifactory:

• Easy to run. Artifactory includes an embedded Jetty server in its binaries, so the user can opt to use the embedded server instead of deploying it to a different application server. The only thing I can see that may be a hassle is that you still needs to set the ARTIFACTORY_HOME environment variable. If you don’t set it, there’ll be problems starting up the server and you won’t even know what is wrong unless you read the documentation.

• Repository configuration. Currently, there is no user interface for configuration. In order to add a repository, you need to add a <localRepository> entry in the artifactory.config.xml file itself and restart Artifactory. It has a feature for importing a repository from a local file system into a local repository in Artifactory. Having no UI for the configuration, you need to have access to the configuration file to know whether the Artifactory repository (where you want to import the artifacts) supports snapshots or releases only, or both. For example, I tried importing a repository containing both snapshots and released artifacts into the default Artifactory repository ‘libs-releases’ and I couldn’t get past importing the repository only to find out that snapshots are not handled in that repo by looking at the config file. A plus for the repository import mechanism is that it has validation checks for the repository paths, you cannot import a repository which has a problem.

• Proxy and cache. The proxying was easy to configure and easy to use. Just set the repositories you want to use in your settings.xml file and it would proxy the remote repositories you’ve set in Artifactory.

• Search and repository browse. Good separation of repositories in the browse. Fast too The artifacts can be downloaded and removed from the repo via the Repository Browse.

• User interface. Artifactory leverages AJAX for it’s user interface, resulting to faster loading of pages. It also has a nice look and feel in comparison with the other repository managers.

• Deploying artifacts. Artifacts can be deployed in an Artifactory repository via the UI.

• Source code. The codebase is small, but not very well-structured. I tried building the source and I couldn’t build it because of some dependencies not being found (tried the profiles but still couldn’t build it). Below is its source structure:
  • core - contains all the core classes such as the proxying, caching, security, scheduling, configuration, search, utility classes, etc.
  • site
  • standalone - the standalone application module (where binary files are assembled)
  • wagon - contains only a class (specific implementation of HttpWagon)
  • webapp - the web app component

DSMP (Dead Simple Maven Proxy)

DSMP is simply just a proxy. As excerpted from its site, it can be used as a repository server but it’s main purpose is to act as a filter when Maven accesses the internet. The version I used here is 1.1.

• Easy to run. A shell script ‘dsmp.sh’ is included in the bundle. But in order to execute the script, you need to update it and set the DSMP_HOME variable to the DSMP installation.

• Proxy. Just redirects request to a proxy repository (thus the name). DSMP does not support hosting a proxy repository. Redirection of proxies can be set through this configuration:

             <redirect from="[PROXIED REPO URL]" to="[PROXY REPO URL]"/>
   
              ex.

<redirect from="http://m2.safehaus.org/org/aopalliance" to="http://maven.sateh.com/maven2/aopalliance" />

• Configuration. The configuration is simple — configuration related to proxies only. In addition to the proxy configuration mentioned above, there is also the concept of "allow" and "deny". Downloading of specific artifacts can be controlled by specifying the URLs or paths which can or cannot be downloaded from a repository. Network proxies can also be set in the configuration if direct connection is not allowed.

• Cache and patches. Caches everything downloaded as well as all failed downloads. DSMP makes use of the concept of patches. It can be configured to look into a specific directory for patches and when it sees a patch for the artifact then it would use that instead of the cached one. Failed downloads are kept in status files, so when DSMP sees these files it would no longer attempt to download the artifact.

• Source code. Very small codebase, a single-module project.

Proximity

Proximity is a Maven proxy for company-wide use. From its website, it is described as basically a "fetch-and-cache engine with various extra capabilities like indexing". The version I’ve used here is 1.0.0-RC9. Below are the features of Proximity:

• Easy to run. Deploying and running the war bundle was easy to do. But this was a little different with the jetty bundle. It would be better if it was specified in the documentation for deploying proximity that JETTY_HOME needs to be set before starting it up. I assumed that all that was needed to run proximity is just to unpack the bundle then start it up by executing the shell script ‘jetty.sh’ included (as specified in the website docs). I also encountered a problem with starting up the jetty bundle, a directory was missing ([PROXIMITY]/bin/logs) so the application couldn’t successfully start up. Manually creating the directory solves the the problem.

• Proxy and cache. The proxying works nicely. What I liked about the proxy feature in Proximity is the repository grouping. Proxy repositories which has the same group ids (for example, group id is ‘public’) are grouped together. This group of repositories can be accessed via a specific URLhttp://localhost:8080/proximity/repository/[GROUP ID] (so it would be http://localhost:8080/proximity/repository/public from the example). You could use this group repository URL in your settings.xml file to tell Maven to download from this group of repositories instead of having to specify each repository URL.

• Repository configuration. Very complex way of configuring repositories, you need to update an xml file and a properties file just to add a new repository.

• Reports/Statistics. Proximity keeps track of the following statistics during run-time (in memory): last 10 served artifacts, where the last 10 requests came from, last 10 local hits, last 10 remote hits, last 10 deployments and where they came from.

• Search and Repository Browse. There are two ways to browse a repository — one is via Browse Artifacts and the other one is via Browse Files. In the Browse Artifacts page, the artifacts are not divided by repository but there are ‘Group’ and ‘Origin’ identifiers to indicate which repository the artifact came from. On the other hand, the artifacts are grouped by repository in the Browse Files page. Specific details such as the directory/file size, md5 and sha1 checksums and URLs are displayed via tool tips when browsing. You can search an artifact across all repositories, by repository or by repository group. There is also a search using Lucene specific queries, examples for this type of queries are available in Proximity’s Search page.

• User interface. The user interface needs more improvement especially the repositories page. It looks a little too crowded and confusing — there’s no separation between the hosted and proxied repositories, only a header of ‘Hosted repository’ or ‘Proxied repository’ identifies which is which.

• Deploying artifacts. Proximity has support for artifact deployment via webdav.

• Maintenance. There are two tasks that are scheduled to be executed at specific times by proximity: re-indexing and repository purge. The actual code for purging the repositories is not yet implemented though. You could see these tasks via the Maintenance page. There is also an option for running re-indexing on a specific repository only (but this is only manually triggered, not scheduled).

• Web services. Services for re-indexing and search.

• Source code. Proximity heavily uses IoC which makes it easy to configure and to plug/unplug components. Below is Proximity’s source structure:
  • px-core - the core module
  • px-core-it - contains integration tests for the core module
  • px-core-maven - contains maven specific functionality
  • px-core-scheduler - contains the task scheduler
  • px-core-ws - module for web services
  • px-webapp-base - contains web controller and utlity classes used by the different webapp ‘flavours’
  • px-webapp-base-it - contains integration tests for the webapp base module
  • px-webapp-default - contains the front-end of the webapp
  • px-webapp-demosite - specific webapp module for the demo site
  • px-webapp-pmaster - specific webapp module for the "master" in Proximity chaining
  • px-webapp-pslave - specific webapp module for the "slave" in Proximity chaining
  • px-webapp-webdav - webdav extension

Features Matrix Comparison

Conclusion

From the matrix above, you can see the differences among these applications and deciding on which one to use really depends on your needs. But setting aside my being an Archiva developer, I think I would still go with Archiva after having tried all of them. With the exception of web services it matches the features of all the others and has a number of features unique to itself, while at the same time it remains one of the easiest to use and has recently become much more stable - so we’re really excited for the 1.0 release this month

Posted on 11.05.07 to Tech blogs by oching. Tagged archiva, artifactory, comparison, dsmp, maven, proximity, proxy, repositorymanager. Subscribe to follow comments on this post. 16 comments. Add your thoughts or trackback from your own site.

• BROWSE / IN TIMELINE
• « Archiva 1.0 Beta 1.. released!
• » Archiva’s Big 1.0!

• BROWSE / IN Tech blogs
• « Archiva 1.0 Beta 1.. released!
• » Archiva’s Big 1.0!