Searching for Components
Searching for components finds information about specific artifacts in the repository. Use this for research into available components, to integrate with your build tool migrations, to download packages, and for quality assurance.
Searching Overview
Component search is available in the search bar at the top and the Search button on the side navigation.
The
nx-search-read
privilege is required to view the search bar and menu button in the user interface.The
repository-view
privilege is required to search a specific repository.Format-specific search forms are nested under the Search button.
More Criteria Drop-down
Use the more criteria dropdown to add additional search criteria to your query. This criteria includes specific metadata fields for the repository as well as format-specific criteria.
Selecting specific criteria adds a new search field for you to enter into.
Criteria may be removed by selecting the minus icon within the criteria input box.
Criteria are not used when nothing is specified in the specific criteria.
Keyword search query string
Tokenization is the process of splitting text into smaller parts, or 'tokens', during indexing and querying. Component metadata and coordinates are tokenized in the Nexus Repository database so the search provides better matching.
When using keyword searches with a hyphenated component name such as aether-util
the query is tokenized to aether
and util
; proving results for both keywords. The tokens of your query string must match a field in one of the indexes exactly.
Using double quotes to narrow results
To match exactly aether-util
, use double quotes in the search term to require the full string for a match.
"aether-util"
Wildcards in searches
Use the asterisk (*) character as a wildcard to broaden search results. Wildcards may be used anywhere in the query string however placing them anywhere except for the last character position may have a performance impact on its execution.
Useaeth*
to findaether
oraether-util
Search Results
After entering search criteria in one or multiple input fields, the first 300 results become visible in the component list. The components are listed with their Name, Group, Version, Format, and Repository information.
Selecting a component in the list changes to a display of the component information.
Notable Search Functionality Differences Between Environments
Search functionality differences exist between the different databases and deployment patterns.
Searching by Conan Package ID and Conan Package or Recipe Revisions are not available for those using OrientDB.
Use a leading slash (i.e., "/") when searching for raw components in H2 or Non-HA PostgreSQL Environment
Search Feature Differences in an HA Environment
The search feature implemented for high availability (HA) differs a great deal from the search currently used in a non-HA environment.
HA search has the following requirements:
At least one search criterion is required when searching through the UI
At least one additional search criterion is required beyond format when searching through the UI
Each search criteria must be at least three characters long
Leading wildcard search is not supported; however, you may use a trailing wildcard (i.e., prefix search)
Searches cannot begin with special characters followed by a wildcard
All keyword searches automatically append a wildcard (*) at the end of each criterion
Example Invalid Search Patterns
The following search patterns are some that may work in non-HA environments but will not work in an HA environment
Invalid Pattern | Reasoning |
---|---|
"*" | Less than three characters long; leading wildcard not supported |
"he*" | Less than three characters long |
"he*@_" | User criteria ("@_") contains only an underscore |
"he*@/" | User criteria ("@/") contains only a forward slash |
"he*@*" | User criteria ("@*") contains only a wildcard |
"/*/hel" | Search begins with a special character followed by a wildcard |
"$%*hel" | Search begins with two special characters followed by a wildcard |
Refetch Limits and Search Configuration Capability
As of 3.72.0, Nexus Repository will only make 10 trips to the database to return a result set in a PostgreSQL HA deployment. You can adjust this limit by creating a Search Configuration Capability specifying a different refetch limit. Setting the refetch limit to "-1" will allow unlimited database queries; however, this can result in slower performance in very large deployments. In some scenarios, the refetch limit may result in missing or empty search results.
You must have clustering enabled to see the Search Configuration capability option.
Search Criteria and Component Attributes
Criteria to use with most repository formats. These return results across all repositories:
Keyword
Use a keyword search to search for a string found in any component metadata value.
Format
The format of the repository in which to look for a component.
Repository Name
The name of a repository in which to look for a component.
Group
The namespace of the component; is often the organization that produces it. Some formats use a different name for this criterion such as
org
for Ivy orgroupId
for Maven while other formats do not use groups such as theNuget
repository format.Name
The name of a component constitutes its main identifier. Different repository formats use a different name for the concept such as artifactId for Apache Maven and the maven2 repository format.
Version
A component's version identifies the specific point in time at which that component was released. Various tools such as Maven or NuGet use the term
version
. Other build systems call this something else (e.g., Apache Ivy usesrev
(short for revision)). In most repository formats, version numbers do not need to follow a specific standard and are simply a string. This affects the sort order and can produce unexpected results.Checksum
A checksum value of a component file generated by an MD5, SHA-1, SHA-256, or the SHA-512 algorithm.
Composer Repositories
Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.
Vendor
The responsible group for the package.
Package
The name of the project.
Conan Repositories
Conan Revisions are available for PostgreSQL or H2 databases only
Arch
The hardware architecture the component was built for.
Base Version
Project or library version (e.g., "1.0.0")
baseVersion.strict
Only return the latest revision for a specific base version.
Compiler
The compiler that was used to package the component.
compiler.runtime
The runtime used by the compiler.
compiler.version
The version of the compiler.
Channel
Channel represents an alternative variant of packages for the same library and usually describes the maturity of the package (e.g., "stable" or "testing"). It also can show package revisions.
Common Version criteria for Conan format is a combination of Base Version and Channel, for instance, "1.0.0-stable"
Os
The operating system the package is to run on.
Package ID (PostgreSQL or H2 databases only)
A Conan Package ID is a unique identifier that encodes information about each package's settings, options, and requirements.
Package and Recipe Revisions (PostgreSQL or H2 databases only)
In simplest terms, revisions are versions of versions. The Conan revisions feature allows you to make changes to your artifacts while maintaining a single Conan reference. Every Conan recipe export is associated with a unique ID (i.e., a revision); every recipe change results in a new recipe revision (RREV). Conan calculates a new package revision (PREV) using the package contents' hash whenever you create a new package. Package revisions belong to recipe revisions; the same package ID may have multiple package revisions belonging to a single recipe revision.
See Conan's documentation on package revisions
Docker Repositories
Image Name
The name for the Docker image. It is equivalent to the Name of the component in the repository manager that represents the Docker image.
Image Tag
The tag for the Docker image. It is equivalent to the Version of the component in the repository manager that represents the Docker image.
Layer Id
The unique identifier for a Docker image layer.
Maven Repositories
Group Id
The Maven groupId for a component. Other build systems supporting the Maven repository format call this differently e.g. org for Apache Ivy and group for Gradle and Groovy Grape. Group Id is equivalent to Group.
Artifact Id
The Maven artifactId for a component. Other build systems call this differently e.g. name for Apache Ivy and Gradle, and the module for Groovy Grape. Artifact ID is equivalent to Name.
Classifier
The Maven classifier for a component. Common values are javadoc, sources, or tests.
Base Version
The base version of the component/asset. Typically this is the same value as the version for release components. SNAPSHOT development components use a time-stamped version but the base version uses the SNAPSHOT version e.g. version of 1.0.0-20151001.193253-1 and base version of 1.0.0-SNAPSHOT.
Extension
The extension is used for a specific asset of a component.
NuGet Repositories
ID
The NuGet component identifier is known as Package ID to NuGet users.
Tags
Additional information about a component formatted as space-delimited keywords, chosen by the package author.
p2 Repositories
Plugin Name
The name of a p2 plugin stored
PyPI Repositories
Classifiers
Denote the maturity, intended audience, license, and supported versions the creator wished associated with their component.
Description
The creator provided a long description of the component.
PyPI Keywords
Associated component keywords. Generally used as identifiers to search.
Summary
The creator described the component.
RubyGems Repositories
Platform
The Platform the gem runs on is defined via the gemspec.
Summary
A summary of the gem's description is defined via the gemspec.
Description
A long description of the gem is defined via the gemspec. This field is optional when creating a gem so may be blank.
Yum Repositories
Package Name
The name of the package, this field is the equivalent of Name for Yum.
Architecture
The architecture the package is designed to be run on.
Preconfigured Searches
Preconfigured searches are available when a repository for the format exists in the repository and the user has repository-view
access to the repository. The format-specific search is available via the format-named menu item in the Search section of the Browse menu.
Each preconfigured search supports adding further criteria.
Keyword Search
The main toolbar includes a Search components text input field. Type your search term and press enter/return and the repository manager performs a search by Keyword.
The same search can be accessed by selecting the Search item in the Browse main menu. The search term can be provided in the Keyword input field in the Search feature view.
Custom Search
A configurable search using the criteria you select is available via the Custom menu item in the Search section of the Browse main menu. Initially, it has no criteria and it allows you to create a search with criteria you add with the More Criteria dropdown.
Search Name | Format | Default Inputs |
---|---|---|
Apt Search |
| Package Name, Version |
Bower Search |
| Name, Version |
CocoaPods Search |
| Package Name, Version |
Composer |
| Vendor, Package, Version |
Conan Search |
| Package Name, Base Version, Channel, Recipe Revision, Package ID, Package Revision, Latest Revision |
Conda Search |
| Package Name, Version |
Docker Search |
| Image Name, Image Tag, Layer ID |
Git LFS Search |
| Name (generated OID found in the pointer file) |
Go Search |
| Name, Version |
Helm Search |
| Name, Version |
Maven Search |
| Group Id, Artifact Id, Version, Base Version, Classifier, Extension |
NuGet Search |
| ID, Tags |
npm Search |
| Scope, Name, Version |
p2 Search |
| Package Name, Plugin Name |
PyPI Search |
| Classifiers, Description, PyPI Keywords, Summary |
R Search |
| Package Name and Version |
Raw Search |
| Name |
RubyGems Search |
| Name, Version, Platform, Summary, Description |
Yum Search |
| Package Name, Version, Architecture |