Another option is to have a single (or a few) pair of Release/Snapshot repositories for your entire organization. In this case, the access is controlled by a mechanism we call “Repository Targets.”
Simply put, a Repository Target is a way to manage a set of artifacts based on their paths. A Repository Target is simply a list of regular expressions and a Name. For example, a Repo Target for Maven would be “./org/apache/maven/. and Nexus OSS would be “./org/sonatype/nexus/.“
Note
while it is most common to manage artifacts based on the path of their groupId, the Regular Expression is matched against the entire path, and so it is also possible, for example, to define “Sources” as “.*-sources.jar” … it’s also worth noting that Repository Targets are not mutually exclusive. It is perfectly valid for a given path to be contained by multiple targets.
In this model, you would create a Repo Target for each project in your system. You are then able to take the Repo Target and associate it with one or more Repositories or Groups in your system. When you do this, new, specific, C.R.U.D. privileges are created. For example, I could take the Maven Repo target, associate it with my Release and Snapshot repository, and now I get privileges I can assign to Create, Read, Update, Delete “Maven” (./org/apache/maven/.) artifacts in my Release and Snapshot repositories.
This method is used to manage the http://repository.apache.org instance, where we have just one Release and Snapshot repository and each project team gets permissions to their artifacts based on the path.
