After illustrating the benefits of a corporate maven repository , we now come to its management and optimal configuration.
Warning: this post is also available in Italian: here
In this article we will use JFrog Artifactory as a reference , but all the activities can be applied to any other semi-free solution as Nexus or Archiva. ( see previous article for tools comparison)
Since I want to focus on management topics, we will refer to official guide to perform base installation: I recommend, if possible, to apply for RPM (or similar) installation package to speedup any future updates, and to install an Apache frontend to better manage server access.
Once you got the server installed, we can connect via web as administrator and begin to configure our remote repository .
The first step is to create our local repositories, my advice is to create at least three of them:
- mycompany -releases : this repo will contain all the stable versions of your projects , only our automated-build tool should be able to upload such artifacts to this repository , no manual intervention should be allowed, in order to enforce the reproducibility of the items uploaded .
- mycompany – snapshots : This repository is the “development twin” of the previous one. Only SNAPSHOT will be hosted and developers can be granted upload permissions in order to speedup libraries sharing within the team .
- mycompany – thirdpaties : This repository will contain all third party libraries you will have to upload manually to make them available to maven. A common problem is absence of some libraries on public maven repositories : whan this happens, you have perform a manual loading of such artifact on the repository to make it available tothe build process. Having a corporate repository, you will not perform such operation on your local maven, but on the shared one in order to make the library globally available.
Using a separate repository you make these libraries easier to identify and organize, so that you can easily remove them once available on maven repository
Warning: a common mistake is to abuse of this repository for laziness , uploading any third party library needed by dev team. Always remember that any library manually loaded will require maintenance and new uploads upon new version releases. Losing a couple of hours on internet searching for a maven repository that exposes what we need (and its future versions) and add it as a remote repository is surely better than making a quick-and-dirty upload and deal with its maintenance ever after.
To set snapshot or release management of a repository you have to configure local repository options accordingly.
For third parties one you can enable both options, since you will be the one who will upload them manually.
Once you have configured local repository, we can start adding remote repositories at will: our corporate repository will act as proxy to each of them. All the main maven repositories are included in the base installation but adding remote repositories is a common practice to make available more third-party libraries we do not want to manually load on our repository.
Basic Artifactory behavior will be fetching artifact from remote repository, store it locally and forward the downloaded object to the maven client which requested it . If you have space issues and you do not want artifact to be stored on your server but requested every time (such artifact will be cached on macen client as well), you just have to enable the option Do not Store Artifacts Locally
We have now completed repositories configuration so we can move on to account configuration.
First of all, let’s analyze what we want to achieve :
- Any user must be able to browse the repository in read-only mode , manually or via search.
This assumed the repository is not public but accessible only on intranet, not being so, such approach is not recommended due to security reasons .
- Developers must be able to upload their work only in snapshot version , but should not be able to load or overwrite any artifacts once in release version.
- On the other hand our build automation tool must be able to deploy both stable and snapshot at the same time.
- Finally we want a server administrator who can manage the upload artifact third party (in our scenario we will assume him to be also Artifactory system administrator )
On first point, resolution is quite simple , as anonymous user is available out-of-the-box.
For developers you could consider creating personal accounts : both Artifactory Nexus can be attached to LDAP directories even if free version does not allow you to manage groups, making maintainance more time-expensive (with no groups you will have to assign permissionsat user level ) .
Honestly, unless you really need audits on who upload different artifacts , a single development user shared with all the team is quite enough to achieve desired effect , so we will create a single developer account.
To our build automation tool we will instead reserve a dedicated account , not being too original we will name it after tool’s name: bamboo.
We also create groups to manage permissions.
Given the low number of users we have, this is quite unneccesary, but we always try to look into the future: assign permissions on groups is much faster and more flexible than having to do the same on individual accounts.
We thus create a group for users who have just read-only access (readers) and one for those who have upload privilege for snaphsots artifacts (devel) .
Since the only one uploading releases will be bamboo user , we will not create a group to him.
Now that we have all users and groups we need, let’s create and assign permissions to perform our restrictions :
As you can see we have created a set of permissions for each repository , plus a global one that includes all the remote repositories .
Now we’ll bind permissions to groups and individual users: we assign release & snapshot deploy permission to our application user, while for the remaining ones, we’ll grant permissions to groups looking forward for a possible user base extension in the future :
Once you’ll have repeated the same operation on all different targets you have completed permissions configuration and our repository will be ready to be used .
In the next post we will see how to configure maven settings to be distributed to developers, to be loaded on the automated-build server to be applied within the maven projects we want to deploy .
See you soon!