With this post I want to start speaking about Maven and Build automation and I want to begin by the introduction of a basic tool for any development team who wants to approach the subject in a professional way :  setting up a remote repository for artifacts.

Warning: this post is also available in italian: here

We all know Maven allows you to automate generation of libraries and other packages (jar , war , ear , zip , etc. ..), generically called “artifact” .
After creating a compiled version of out code, maven can store it in a local repository , making it instantly available to any other build made ​​on the same machine which requires it as a  direct or transitive dependency,  .
In the same way any other third party dependency is automatically searched by the build procedure, at first on the local repository ( if it has already been downloaded and cached ) and then on all the remote repositories set in the configuration ( maven contains the default remote repository maven central) or the pom itself.

So, which are the advantages of creating a new remote repository dedicated to our build ?

There are several pros (and of course also some small cons) , we try to analyze them one by one:

• Artifact team sharing : stopping at local repository you cannot share libraries produced with your whole team. Each member should checkout updated code of all libraries and build always the entire set to be sure to use latest version on his local repository.
  With rare exceptions , no third-party remote repository would allow you to upload your code for personal use ( and I suppose that ,unless in Open Source projects, very few would be willing to make it  publicly available on the internet). It is therefore mandatory to have your team ( or even corporate ) repository on which developers can upload the output of their builds and from which they can retrieve their colleagues work. In this way, each developer worry only about the code he own, downloading additional dependencies directly from the repository , no more wasting time rebuilding everything.
• Effective separation of artifact still under development and release : allowing the distinction between SNAPSHOT (ie still open to development) and “release “versions , you have an immediate evidence if the artifact you are using as a dependency within your own work is a stable version or still subject to change by the author. In addition, the stable versions are typically unchangeable once they are uploaded to the repository, then you cen be 100% sure that the released code will not change over time, while on snapshot you can sill ask owner about some changes.
• Centralize libraries management: a repository is not simply an hosting fo rartifacts produced by the development team, but it can act as a proxy for all the maven repository available on the web. The advantage of this approach is that each “client” speaks with a single global repository ,avoiding the risk that different elements of the team rely on different repositories or even add new ones, not available to the rest of the group , introducing problems with compatibility and / or compilation once you share projects.
  Having a single master repository (which takes care of query in turn remote repositories according to an established policy priority ) we are guaranteed that the artifact downloaded by each developer for each team will be always the same, without  anomalies , since each new repository can no longer be added by individuas, but will have to be configured on the corporate repository and then immediately shared.
• As suggested by Richard Duncan on Linkedin , another big advantage for those working in the open source world is the fact that a corporate repository also allows you to keep under control the “nature” of third-party libraries used in your own projects, thus avoiding to introduce elements not compliant with corporate policies ( not-Open-Souce libraries, untrusted libraries, etc.. ) .
  Using your own repository as a proxy to other external repositories and appropriately exploiting the patterns include / exclude it is possible to adjust and eventually filter libraries which builds can access, excluding unwanted ones.

Among the cons ( there’s always a “con ” ) we surely have to mention the single point of failure that you’re introducing in your build chain. If the repository is unique, its possible crash would block the whole process. So pay close attention to the kind of machine you will install as it will bear the burden of all requests for artifacts from all your teams and ensure you have enough space available to store several thousand libraries (remember that for each library there will be different versions , both stable or SNAPSHOT )

Let us now focus on more practical topics: which are the tools to choose from? Staying in the semi- free field there are three main options: JFrog’s Artifactory , Sonatype ‘s Nexus ( Maven itself authors) and Apache’s Archiva , for an effective comparison , I suggest you to refer to this excellent comparison table

JFrog’s Artifactory

Sonatype’s Nexus

Apache’s Archiva

Archiva is (obviously) apache-licensed , while Nexus and Artifactory have both a free version with limited functionality (but still more than enough for our purposes ) together with a pro edition available for a fee.

Personally, I got to work with the last two in the free edition, and in both cases I consider them great products, then I would advise you to go through the comparison matrix and choose according to your actual needs .

Just to provide an example I always opted for Artifactory because of the capability to show source code within artifacts  directly from the web interface , a feature that Nexus reserves to Pro users, but I’ve always considered such feature extremely useful to perform troubleshooting in the event any doubt may arise about what had actually been released in the package.

Nexus on the other hand has his strength in management of large number of repository, regardeless they are local ( installed on the same nexus machine), remote ( for which the repo acts as a proxy ) or virtual ( a kind of ” aggregate view ” of any number of previous two to expose them as a single repository ) .
The same functionality is of courseavailable on Artifactory , but  Nexus ExtJs / Sencha interface makes administration much easier and intuitive .

Let’s stop here with analysis, on next post we’ll jump over more practical configuration and administrator topics, using Artifactory as a reference tool.