{inall}
Once you decide to install a {nxrm}, the next decision is how to set up your repositories, particularly if you have multiple teams sharing the same instance. {nxrm} is very flexible in this area and supports a variety of configurations. We first describe the options and then discuss the thought process used to decide what makes sense for your organization.
The first and most obvious way to support multiple teams is to configure a pair of repositories per team (one release, one snapshot). The team is then given the appropriate C.R.U.D. permissions, and they are able to use the system for their components.
Another option is to have a single pair (or a few pairs) of release and snapshot repositories for your entire organization. In this case, the access is controlled by repository targets.
Simply put, a repository target is a way to manage a set of components based on their paths in a repository. A repository target is simply a list of regular expressions and a name. For example, a repository target pattern for Apache Maven would be ./org/apache/maven/. or for {oss} it would be ./org/sonatype/nexus/..
|
Note
|
While it is most common to manage components 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 is 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 repository target for each project
in your system. You are then able to take the repository target and
associate it with one or more repositories or repository groups. This
creates new C.R.U.D. privileges specific to the reposiory or
group. For example, you could take the Maven repository target,
associate it with the release and snapshot repository. You get
privileges you can assign to Create, Read, Update, Delete "Maven"
(./org/apache/maven/.) components in the 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 components based on the path.
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 components regardless of the path. You
still associate the default repository target with specific repositories to
create the assignable privileges
In general, fewer repositories will scale better and are easier to manage. It’s also easier to start off with a single pair of repositories with the default 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, i.e. they can’t read each other’s components, then this solution might be more applicable as well.
In summary, {nxrm} allows you to control the security of your components based on the repository and/or the path of the components, meaning it is possible to slice and dice the system any way you see fit. The default suggestion is to use as few hosted repositories as possible and control the permissions by using repository targets.