Routing can be considered the internal activities Nexus performs in order to determine where to look for a specific component in a repository. The routing information has an impact on the performance of component retrieval as well as determining the availability of components.
A large portion of the performance gains achievable with correct and optimized routing information is configured by Nexus itself with automatic routing, documented in Section 6.4.1, “Automatic Routing”. Fine grained control and further customizations in terms of access provision can be achieved with some manual routing configuration documented in Section 6.4.2, “Manual Routing Configuration”.
Automatic routing is handled by Nexus on a per repository basis. You can access the configuration and further details in the Routing tab after selecting a repository in the list accessible via the Repositories item in the the Views/Repositories left-hand menu.
The routing information consists of the top two levels of the directory structure of the repository and is stored in a prefixes.txt file. It allows Nexus to automatically route only component requests with the corresponding groupId values to a repository, as found in the text file. This, in turns, avoids unnecessary index or even remote repository access and therefore greatly improves performance.
Nexus generates the prefixes.txt file for a hosted repository and makes it available for remote downloads. Each deployment of a new component will trigger an update of the file for the hosted repository as well as the prefix files for any repository groups that contain the hosted repository. You can access it in the Routing tab of a hosted repository as displayed in Figure 6.17, “Automatic Routing for a Hosted Repository” by clicking on the Show prefix file link on the right. In addition, the Publishing section shows the Status of the routing information, a Message with further details, and the date and time of the last update in the Published On field.
The Routing tab for a proxy repository displayed in Figure 6.18, “Automatic Routing for a Proxy Repository” contains the Discovery section. It displays the Status and a more detailed Message about the prefix file access. The Last run field displays the date and time of the last execution of the prefix file discovery. Such an execution can be triggered by pressing the Update now button. Otherwise, the Update Interval allows you to trigger a new discovery every one, two, three, six, nine or twelve hours or as a daily or weekly execution.
For a proxy repository, the prefix file is either downloaded from the remote repository or generation is attempted by scraping the HTML directory listing of the remote repository. If a prefix file is published by the remote it is always used. The scraping strategy only used in cases where Nexus can be sure the remote directory listing contains all available artifacts. For example, if the remote is a Nexus hosted repository, or a well known format such as a Subversion based repository then the directory listing will be used if no prefix file is available.
The generation of the prefix file in all the Nexus deployments proxying each other greatly improves performance for all Nexus instances. It lowers network traffic and load on the servers, since failing requests and serving the respective HTTP error pages for a component that is not found is avoided for each component. Instead, the regularly light weight download of the prefix file establishes a good high-level knowledge of components available.
Automatic Routing is configured by Nexus automatically brings significant performance benefits to all Nexus instances proxying each other in a network and on the wider internet. It does not need to be changed apart from tweaking the update interval. To exercise even finer control than provided by Automatic Routing use Routing as documented in Section 6.4.2, “Manual Routing Configuration”.
Nexus routes are like filters you can apply to groups in terms of security access and general component retrieval, and can reduce the number of repositories within a group accessed in order to retrieve an component. The administration interface for routes can be accessed via the Routing menu item in the View/Repositories menu in the left-hand navigation panel.
Routes allow you to configure Nexus to include or exclude specific repository content paths from a particular component search when Nexus is trying to locate a component in a repository group. There are a number of different scenarios in which you might configure a route.
The most commonly configured scenario is when you want to make sure that you are retrieving components in a particular group ID from a particular repository. This is especially useful when you want your own organization’s components from the hosted Release and Snapshot repositories only.
Routes are applicable when you are trying to resolve a component from a repository group. Using routes allows you to modify the repositories Nexus will consult when it tries to resolve a component from a group of repositories.
Figure 6.19, “Routing Configuration Screen in Nexus” shows the Routing configuration screen. Clicking on a route will bring up a screen that will allow you to configure the properties of a route. The configuration options available for a route are:
- URL Pattern
Nexus uses the URL Pattern will use to match a request to Nexus. If the regular expression in this pattern is matched, Nexus will either include or exclude the listed repositories from a particular component query. In Figure 6.19, “Routing Configuration Screen in Nexus” the two patterns are:
This pattern would match all
paths that start with either
/org/somecompany/. The expression in the parenthesis matches either com or org, and the
.*matches zero or more characters. You would use a route like this to match your own organization’s components and map these requests to the hosted Releases and Snapshots repositories.
This pattern is used in an exclusive
route. It matches every path that starts with
/org/some-oss/. This particular exclusive route excludes the local hosted Releases and Snapshots directory for all components that match this path. When Nexus tries to resolve components that match this path, it will exclude the Releases and Snapshots repositories.
- Using this pattern in an exclusive route allows you to exclude everything, except the "org/some-oss" project(s). It uses a special negative matching regular expression.
- Rule Type
- Rule Type can be either inclusive, exclusive or blocking. An inclusive rule type defines the set of repositories that should be searched for components when the URL pattern has been matched. An exclusive rule type defines repositories which should not be searched for a particular component. A blocking rule will completely remove accessibility to the components under the specific pattern in a specified repository group.
- Ordered Route Repositories
- Nexus searches an ordered list of repositories to locate a particular component. This order only affects the order of routes used and not the order of the repositories searched. That order is set by the order of the repositories in the group repository’s configuration.
In Figure 6.19, “Routing Configuration Screen in Nexus” you can see the two dummy routes that Nexus
has configured as default routes. The first route is an inclusive
route, and it is provided as an example of a custom route an
organization might use to make sure that internally generated
components are resolved from the Releases and Snapshots repositories
only. If your organization’s group IDs all start with
com.somecompany, and if you deploy internally generated components to
the Releases and Snapshots repositories, this Route will make sure
that Nexus doesn’t waste time trying to resolve these components from
public repositories like the Central Repository or the Apache
The second dummy route is an exclusive route. This route excludes the
Releases and Snapshots repositories when the request path contains
/org/some-oss. This example might make more sense if we replaced
codehaus. If the pattern was
/org/apache, this rule is telling Nexus to exclude the internal
Releases and Snapshots repositories when it is trying to resolve these
dependencies. In other words, don’t bother looking for an Apache
dependency in your organization’s internal repositories.
Exclusive rules will positively impact performance, since the number of repositories that qualify for locating the component, and therefore the search effort is reduced.
What if there is a conflict between two routes? Nexus will process inclusive routes before it will process the exclusive routes. Remember that routes only affect Nexus' resolution of components when it is searching a Group. When Nexus starts to resolve a component from a repository group it will start with the list of repositories in a group. If there are matching inclusive routes, Nexus will then take the intersection of the repositories in the group and the repositories in the inclusive route. The order as defined in the group will not be affected by the inclusive route. Nexus will then take the result of applying the inclusive route and apply the exclusive route to that list of repositories. The resulting list is then searched for a matching component.
One straightforward use of routes is to create a route that excludes
the Central Repository from all searches for your own organization’s
hosted components. If you are deploying your own components to Nexus
under a groupId of
org.mycompany, and if you are not deploying these
components to a public repository, you can create a rule that tells
Nexus not to interrogate Central for your own organization’s
components. This will improve performance because Nexus will not need
to communicate with a remote repository when it serves your own
organization’s components. In addition to the performance benefits,
excluding the Central Repository from searches for your own components
will reduce needless queries to the public repositories.
This practice of defining an inclusive route for your internal
components to only hit internal repositories is a crucial best practice
of implementing a secure component management in your
organization and a recommended step for initial Nexus
configuration. Without this configuration, requests for internal
components will be broadcasted to all configured external proxy
repositories. This could lead to an information leak, where e.g., your
internet traffic reveals that your organization works on a component
with the component coordinates of
In addition to defining inclusive and exclusive routes, you can define blocking routes. A blocking route can be created by creating a route with no repositories in the ordered list of repositories. It allows you to completely block access to components with the specified pattern(s) from the group. As such, blocking routes are a simplified, coarse-grained access control.
Check out Chapter 10, Nexus Procurement Suite for fine-grained control of component availability and use blocking routes sparingly.
To summarize, there are creative possibilities with routes that the designers of Nexus may not have anticipated, but we advise you to proceed with caution if you start relying on conflicting or overlapping routes. Use routes sparingly, and use coarse URL patterns. Remember that routes are only applied to groups and are not used when a component is requested from a specific repository.