Searching for Components

Due to ongoing work for improving component search in Sonatype Nexus Repository, some functionality differences currently exist between deployments using OrientDB, H2, PostgreSQL, and/or High Availability (HA). Take note of the specific differences and considerations in the sections below before you begin searching for components.

Searching for components allows you to quickly identify and access information about specific components (e.g., available versions, security and license data, etc.). This can be especially helpful for activities such as build tool migrations, downloading deployment packages, and other component-related development, QA, and operations acitivities.

Component search is available in a few places: through the search input in the top navigation, through the main Search button in the left-hand navigation, or through one of the specific format buttons nested under Search in the left-hand navigation.

Beneath the search title is the search criteria input area that displays the current criteria input (e.g., Keyword). Beside the current criteria is a More criteria drop-down menu that allows you to add additional criteria to your search. Each criteria can be removed by selecting the minus/dash icon within the criteria input box. The cross/x in the input box resets the value.

Each criteria can be used together to allow for broad or fine search results. For example, searching on name foo might return a large number of Maven, NuGet, and other components but adding a version could limit it to what you’re searching for. The Keyword field also supports the * (star, asterisk) character for wildcard matching. For example, a keyword search for org.sonatype.nexus* would return components containing org.sonatype.nexus, org.sonatype.nexus.plugins, and any other matches. If nothing is specified in a criteria, the results have no reductions based around that criteria.

The query you enter is passed into the indexes made against every component in the system. These indexes contain the component coordinates as well as any metadata attached to the component. Some of these indexes contain data that has been tokenized (for example, strings split on a hyphen, so aether-util would match 2 search terms, aether or util), while other indexes do not (imagine wanting to search for "aether-util" (see below for more details on double quotes), this would require the full name to match against, rather than a tokenized version). Without wildcards, your query string must match a field in one of these indexes exactly, wildcards can save you when you just can't remember the exact name, but have some partial idea.

About wildcards, how do they change my queries?

Let's suppose you did a query for aeth, and it returned no results, as the component you are trying to match needs the full term aether to make a match. So you can then use aeth* and this would now match the aether-util component you were initially searching for. Keep in mind that you can use wildcards anywhere in the query string, but placed anywhere except for the last character position has potential to cause the query to run slow.

Using a hyhpen in my query generates a lot of results, how can I make this more manageable?

Along with tokenizing strings for search terms in some of the indexes, we also do the same to the query string you type, so if you type aether-util we will show all results that would match aether or util. Suppose you know you want exactly aether-util and want to filter out all the other results that were brought in, you can use double quotes in your search term, "aether-util" for example, this would then no longer tokenize your query string, but require the full string for a match.

Once you have provided your search terms in one or multiple criteria input fields, like the Keyword criteria in the Search feature view, the first 300 results become visible in the component list.

The components are listed with their Name, Group, Version, Format and Repository information and by default are sorted alphabetically by Name. Columns and sort order can be adjusted like in all other lists.

Selecting a component in the list changes to a display of the component information documented in Viewing Component Information.

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.

Apt Search

The Apt search is a predefined search available via the Apt menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name and Version and supports adding further criteria. The format is configured to apt.

Bower Search

The Bower search is a predefined search available via the Bower menu item in the Search section of the Browse menu. It defaults to inputs for Name and Version and supports adding further criteria. The format is configured to bower.

CocoaPods Search

The CocoaPods search is a predefined search available via the CocoaPods menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name and Version and supports adding further criteria. The format is configured to cocoapods.

Conan Search

The Conan search is a predefined search available via the Conan menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name, Base Version and Channel and supports adding further criteria. The format is configured to conan.

Conda Search

The Conda search is a predefined search available via the Conda menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name and Version and supports adding further criteria. The format is configured to conda.

Docker Search

The Docker search is a predefined search available via the Docker menu item in the Search section of the Browse main menu. It defaults to inputs for Image Name, Image Tag and Layer Id and supports adding further criteria. The format is configured to docker.

Git LFS Search

The Git LFS search is a predefined search available via the Git LFS menu item in the Search section of the Browse main menu. It defaults to an input for Name and supports adding further criteria. The format is configured to gitlfs. Note that since Git LFS is not provided with the original filename for a tracked file, the Name field actually contains the generated OID which can be found in the corresponding pointer file’s contents.

Go Search

The Go search is a predefined search available via the Go menu item in the Search section of the Browse main menu. It defaults to an input for Name and Version and supports adding further criteria. The format is configured to go.

Helm Search

The Helm search is a predefined search available via the Helm menu item in the Search section of the Browse main menu. It defaults to inputs for Name and Version and supports adding further criteria. The format is configured to helm.

Maven Search

The Maven search is a predefined search available via the Maven menu item in the Search section of the Browse main menu. It defaults to inputs for Group Id, Artifact Id, Version, Base Version, Classifier and Extension and supports adding further criteria. The format is configured to maven2.

NuGet Search

The NuGet search is a predefined search available via the NuGet menu item in the Search section of the Browse main menu. It defaults to inputs for ID and Tags and supports adding further criteria. The format is configured to nuget.

npm Search

The npm search is a predefined search available via the npm menu item in the Search section of the Browse main menu. It defaults to inputs for Scope, Name, and Version and supports adding further criteria. The format is configured to npm.

p2 Search

The p2 search is a predefined search available via the p2 menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name and Plugin Name and supports adding further criteria. The format is configured to p2.

PyPI Search

The PyPI search is a predefined search available via the PyPI menu item in the Search section of the Browse main menu. It defaults to inputs for Classifiers, Description, PyPI Keywords,and Summary and supports adding further criteria. The format is configured to pypi.

R Search

The R search is a predefined search available via the R menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name and Version and supports adding further criteria. The format is configured to r.

Raw Search

The Raw search is a predefined search available via the Raw menu item in the Search section of the Browse main menu. It defaults to an input for Name and supports adding further criteria. The format is configured to raw.

RubyGems Search

The RubyGems search is a predefined search available via the RubyGems menu item in the Search section of the Browse main menu. It defaults to inputs for Name, Version, Platform, Summary and Description and supports adding further criteria. The format is configured to rubygems.

Yum Search

The Yum search is a predefined search available via the Yum menu item in the Search section of the Browse main menu. It defaults to inputs for Package Name, Version and Architecture and supports adding further criteria. The format is configured to yum.

Sometimes it is necessary to determine the version of a component, where you only have access to the binary file without any detailed component information. When attempting this identification and neither the filename nor the contents of the file contain any useful information about the exact version of the component, you can use SHA-1 search to identify the component.

Create a sha1 checksum, e.g., with the sha1sum command available on Linux or OSX or fciv on Windows, and use the created string in a Custom search by adding the SHA-1 criteria from the Checksum section of the More criteria control.

The search will return a result, which will provide you with the detailed information about the file allowing you to replace the file with a dependency declaration. E.g. you can derive the Maven coordinates of a jar file and use them in a dependency declaration.

A SHA-1 or similar checksum search can be a huge timesaver when migrating from a legacy build system, where the used libraries are checked into the version control system as binary components with no version information available.

Once you located a component via a search and selected it in the list, you see the component information. An example is displayed in Figure: “Example for Component Information and List of Associated Assets”.

The information displayed includes the name and format of the repository that contains the component as well as the component identifiers Group, Name, and Version. Most popular version contains the version number of the same component that is most popular in its usage within a specific group and name. Popularity shows a relative percentage of popularity between the displayed component against all other versions of this component. A value of 100% signals this version to be the most popular. 50% means that the specific version is half as popular as the most popular version. Popularity data is provided by the Sonatype Data Services based on requests from the Central Repository and other data and not available for all components. Age shows the age of the component.

None of the popularity or age data is viewable without Repository Health Check enabled, as lightly touched on in Managing Repositories and Repository Groups.

A list of one or more assets associated with the component is shown below the component information. Click on the row with the Name of the asset you want to inspect to view the asset information documented in Viewing Asset Information.

To delete a component press the Delete component button. A modal will pop up to confirm the deletion. You can only delete components from hosted and proxy repositories. A deletion of a components triggers the deletion of all its associated assets, in most repository formats.

In some repository formats assets are shared across components. They remain after a component deletion. For example, while a Docker image is a component and can be deleted, the layers that make it up remain after its deletion as these assets are potentially shared with other Docker images.

To analyze an application, press the Analyze application button. A form will pop up to request further information from you: email address, report password, a list of proprietary packages for the application, and a name for the report. Once you provide this information, press the Analyze button as shown in Figure: “Analyze Application Form”. Your report link will be emailed to you as soon as it is finished.

Asset information can be accessed from a component information view. The Delete button allows you to remove an asset. The information itself is broken up into sections, accessible by tabs below the Delete Asset button. The Summary section contains a number of attributes about the specific asset. An example for search is displayed in Figure: “Asset Info Example”.

Path:

the path to the asset in the repository. This is a link, either downloadable or loading in browser dependent on the contents of the asset.

Content type:

the MIME type of the asset

File size:

the size of the file

Blob created:

the date and time when the asset was created in the Sonatype Nexus Repository blob store

Blob updated:

the date and time when the asset was updated last in the Sonatype Nexus Repository blob store. This will initially match Blob created.

Last 30 days:

the number of times the asset was downloaded in the last thirty days

Last downloaded:

the date when the asset was last downloaded (or updated). It will be updated when the asset is first downloaded and then on subseqent 200 and 304 responses. By default, this is prevented from updating too often for performance reasons and will only update once in any given 12 hour period. It is possible to override this setting by adding a Storage Settingscapability (shown below) and configuring the'Last Downloaded' Update Interval value.

Locally cached:

value of true means the asset can be found in the repository manager storage while false indicates that the metadata about the asset is available, though the asset itself has not been downloaded

Blob reference:

a unique identifier pointing at the the binary blob representing the asset in the repository manager storage

Uploader:

user who uploaded the asset

Uploader's IP Address:

the IP address of the indiviual who uploaded or requested the asset

The Attributes section contains further metadata about the asset related to Cache, Checksum, and Content attributes. Assets can include format specific attributes displayed in additional sections. For example an asset in a Maven2 repository has a Maven2 section with attributes for extension, baseVersion, groupId, artifactId, version, and asset_kind.

In Sonatype Nexus Repository Pro, two additional tabs named Component Tags and Component IQ are available. The Component Tags tab contains a list of tag names (firstCreated and lastUpdated dates) associated with the selected component. When a row in this table is clicked the user will be presented with the tag deatails.

If Repository Health Check is enabled (on a Professional licensed system) or Nexus IQ Server is connected, the Component IQtabshows security information and license details about a component, if available to that format and from Sonatype.

The nx-search-read Privilege gives access to this left nav item as well as the sub-item Search - Custom. In order to get access to format specific searches, you must have the associated format repository-view privileges. For example, if you want to see the Maven sub-item you need to have repository-view privilege for at least one Maven repository.