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.

Changes to Search in 3.88.0
In version 3.88.0, Sonatype Nexus Repository moved fully to SQL search and removed Elasticsearch. With this change, search behavior is more precise, and some previously supported wildcard patterns no longer work. For details, see our SQL Search documentation.

Searching Overview

Component search is available in the search bar at the top and the Search button on the side navigation. The following permissions are required to use the search bar in the UI and find components from specific repositories:

nx-search-read
repository-view (per repository)

After entering a search, the first 300 results are visible in the component list. Selecting a component in the list changes to a display of the component information.

Note that result ordering may depend on the configured database; relevance ranking requires using a PostgreSQL database.

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.

• Hyphenated keywords

When using keyword searches with a hyphenated component name such as aether-util, the query is tokenized to aether and util, providing results for both keywords. The tokens of your query string must exactly match a searchable field.

Tokenization does not include fuzzy or stemmed matching. See SQL Search for details.

• 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 component search results.

• Trailing wildcards are supported. Place the wildcard at the end of your search term. By default, users must enter at least 3 characters before a wildcard. For example aeth* finds aether or aether-util.
• By default, leading and embedded wildcards are not supported. Searches like *maven or ja*y are not supported.
• When nexus.search.multi.wildcard.regex.enabled is enabled, supported component search fields can use positional wildcard patterns. Positional wildcard patterns preserve the order of the search terms. For example, commons*lang matches commons-lang, but does not match lang-commons. Supported fields include group, namespace, organization, name, artifact ID, package name, and version. Positional wildcard patterns are not supported for keyword search or format-specific fields, such as Maven base version, Docker tags, and npm scope. For more information, see SQL Search.
• New in 3.95 The minimum number of characters required before a trailing wildcard is configurable. See Configure Minimum Prefix Length for Trailing Wildcards.

Configure Minimum Prefix Length for Trailing Wildcards

You can configure the minimum number of characters required before a trailing wildcard through the nexus.search.wildcard.minPrefixLength property.

By default, SQL search requires at least three characters before a trailing wildcard (*). You can configure the nexus.search.wildcard.minPrefixLength property in the nexus.properties file located in the data directory at $data-dir/etc/nexus.properties. The property accepts integer values within a validated range of 1 to 100. When the property is not specified, Nexus Repository uses the default value of 3 characters. Restart your Nexus Repository instance after you change the configuration.

Example:

nexus.search.wildcard.minPrefixLength=1

The above configuration allows searches with a single-character prefix, such as version=1.*`. Note that lower values may match more components, potentially affecting query performance on large repositories.

For HA deployments, every node has its own configuration. Make sure to update the nexus.properties for each node.

Search Fields and Component Attributes

Note
Nexus Repository adopted SQL search from versions 3.88 and later. It introduced format specific behavioural differences. For more details, see SQL Search documentation.

This section explains the different search fields available in Nexus Repository to narrow down the results.

The following are the search fields available for all the 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 or groupId for Maven while other formats do not use groups such as the Nuget 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 uses rev (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 RepositoryTM 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 Nexus 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 results

No results found.