Repository Management with Nexus
17.4. Selecting an Approach

17.4. Selecting an Approach

First of all, these choices aren’t mutually exclusive. In fact, the first option builds upon the default Repository Target of “.*” which simply gives you access to all artifacts regardless of the path. You still associate the default Repo Target with specific repositories to create the assignable privileges

In general, it’s my opinion that fewer repositories will scale better and are easier to manage. It’s also easier to start off with a single pair of repos, with the default “All M2″ (.*) target and simply refine the permissions as you scale. Most things that are configured per repository (Cache, Storage location, Snapshot purging, etc) will generally be applicable for all projects, so this mode avoids the duplication of these tasks. Since everything will be stored together in a single folder on disk, it makes backups easier as well.

The reasons why you would want multiple sets of repositories is essentially the opposite of above: If you need different expiration, Snapshot purging or storage folders, then a single shared repo won’t work. Replication and failover strategies may also make this method easier to support. If you absolutely must maintain total separation between Project teams, ie they can’t read each other’s artifacts, then this solution might be more applicable as well. (but is still possible with Repo Targets…just grant Read to only the appropriate targets)

In Summary, Nexus allows you to control the security of your artifacts based on the repository and/or the path of the artifact, meaning it is possible to slice and dice the system any way you see fit. My default position is to use a few Hosted Repositories as possible and control the permissions by the Repository Target.

Sonatype Promotion Subscribe via RSS