Guidelines when splitting artifact repositories

Question

I am looking for an article which describes a set of guidelines to follow when creating repositories in an artifact repository manager.

I know that:

• You need to keep snapshots in snapshot repositories.

• You need to keep releases in release repositories.

• Third-party artifacts should be in a separate repository (the same goes for forked/patched versions of third-party libraries).

• It's generally a good idea to prefix the names with int-* and ext-*.

• Usually different product lines end up having their own repositories as sometimes their artifacts don't depend on each other.

I've been trying to find an article on this to illustrate to a client how this artifact separation abstraction is done by other companies and organizations using repositories.

Many thanks in advance!

Answer 1

I am not aware of existence of such an article, but as @tieTYT mentioned, you can look at Artifactory default repositories. They reflect years of experience in binaries management, continuous integration and delivery. Those practices still apply even if you use Nexus (and you can observe them even without installing Artifactory, by looking at JFrog public Artifactory instance http://repo.jfrog.org)

For your convenience, here are the defaults (important usage emphasised):

Local Repositories:

• libs-snapshot-local: Deploy here your local snapshots
• libs-release-local: Deploy here your local releases
• ext-snapshot-local: Deploy here 3rd-party snapshots which aren't available in remote repos
• ext-release-local: Deploy here 3rd-party releases which aren't available in remote repos
• plugins-snapshot-local: Deploy here your plugin (usually, maven) snapshots
• plugins-release-local: Deploy here your plugin (usually, maven) releases

Remote Repositories:

• jcenter: proxy of http://jcenter.bintray.com. Normally, that's the only remote repo you'll need. It includes whatever exists in maven central plus all other major maven repositories

Virtual Repositories:

• remote-repos: aggregation of all the remote repositories
• libs-release: this is the resolution repository for release builds. It includes remote-repos, libs-release-local and ext-release-local
• libs-snapshot: this is the resolution repository for snapshot builds. It includes remote-repos, libs-snapshot-local and ext-shapshot-local
• repo: this is special virtual repository, that aggregates everything. Generally, do not use it, if you ever plan building release pipeline using binary repository.

I'll be glad to advice on specific question.

Answer 2

As is the case with many questions about best practices, the answer is: It depends.

Technically there are only two distinctions that are required:

• Snapshot vs release repo

• Hosted vs proxy repository

Snapshots vs release repositories as a distinction is required since the Maven repository format and therefore Maven and other build tools differentiate how they work with the the meta data and what they do during upload.

For proxy repositories you will just have to add as many you need to proxy. This will depend on what components you require and will be separate for proxying snapshot and release repos.

For hosted repositories you also have to have separate snapshot and release repos. Beyond that is is all up for grabs. Having a separate third party repo as preconfigured in Nexus (and Artifactory) and other setups are certainly useful, but not really necessary. You can have all those distinctions sorted out by internal meta data where required.

Along the same lines you can have one release repo for everyone or one for each team or whatever. You can still apply access rights within those repositories to separate access and so on in Nexus with repository targets. I assume Artifactory and Archiva can do something similar. The question here mostly boils down to ease of administration, backups, security setup and access for users.

Naming conventions like you mentioned can help if you want to have separate repositories, but technically none of this is necessary.

Other things I have seen are e.g. migration repos that are used to migrate legacy project libraries into a repo but become frozen after the migration is done, separate repos per team, separate repos per project and so on. Another aspect are separate repos for different levels of approval and so on (e.g. check out problems with that on http://blog.sonatype.com/people/2013/10/golden-repository/)

In the end however this all hinges really on usability and meta data and is not required. Ultimately these repositories will in most cases grouped together and accessed via one group, which flattens out the whole separation. And access rights still carry through into the group so everything can still be controlled as you like. So it turns to be a matter of taste on how you want to slice and dice and manage it.

PS: I am referring to the Maven repositories and format. Once you add a whole bunch of other formats into the mix and wrappers around them exposing them in other formats, everything gets more complicated, but the ideas behind things stay similar.