How Components are Defined within Nexus Repository

How Components are Defined within Nexus Repository

Sonatype Nexus Repository supports many repository formats; this topic provides detail on how Nexus Repository counts components for each ecosystem. This information is crucial to understanding the component counts visible in your Nexus Repository usage metrics.

Note
In Nexus Repository, a component typically refers to a unique package or module and its associated metadata. For most formats, this corresponds to a single file or group of related files.

Format-Specific Component Identification

This section goes through each format that Sonatype Nexus Repository supports and how Nexus Repository counts a single component of that format. You can use this information to better understand the component counts visible in your Nexus Repository usage metrics.

APT (Debian)

Nexus Repository counts each.debpackage as one component for the APT format. It does not count associated metadata (e.g., Packages.gz files) as components.

Bower (Deprecated)

While Nexus Repository no longer supports Bower format, older versions counted a single Bower component as a.ziparchive and itsbower.jsonfile.

Cargo

A single Cargo component is typically one.cratefile. Nexus Repository uses Name and Version to identify individual Cargo components (e.g., grin : 1.1.0).

CocoaPods

A CocoaPods component is a single.tar.gzfile. Nexus Repository identifies CocoaPods components by Name and Version (e.g., libpng : 1.4.9).

Composer

A Composer component is typically one.zipfile. Nexus Repository uses Namespace, Name, and Version to identify Composer components. For example, symfony : event-dispatcher : v7.2.0 represents the component symfony/event-dispatcher version v7.2.0.

Conan

A single Conan component typically includes multiple files:

These files are stored as multiple assets in Nexus Repository, but they are grouped as one component. Nexus Repository identifies Conan components by Name, Version, Owner (optional), and Channel (optional). For example, libxml2 : 2.9.8 : bincrafters : stable represents a single Conan component.

Docker

In Nexus Repository, a Docker component is defined as a tagged manifest, which is a metadata file that lists the binary layers that make up a Docker image.

Tags and layers do not count towards component totals. Tags are aliases pointing to manifests. Layers are binary blobs referenced by manifests; they are shared and stored once across images. Layers are not components even though they consume the most storage.

What does this mean for component counts? Here are some examples:

GitLFS

Nexus Repository considers one binary file, stored separately from the Git repository, to be a single component.

Helm

A Helm component consists of a.tgzHelm chart archive. These archives contain multiple YAML files; however, Nexus Repository counts the archive as a single component.

Hugging Face (hf-model)

A single Hugging Face component is one model file (e.g., pytorch_model.bin). This file might be .bin, .safetensors, .onnx, etc., depending on the model format. Nexus Repository identifies a Hugging Face model by Repository ID, Model Name, Version, Model Format, and Extension as in the following example:

Maven

Nexus Repository identifies Maven components by Group ID, Artifact ID, and Version (GAV coordinates) (e.g., org.sonatype.nexus : nexus-indexer : 1.0). A single Maven component in Nexus Repository can include multiple related files (e.g., .jar, pom.xml, source jar, hash files), all sharing the same GAV.

NuGet

Nexus Repository identifies NuGet components by Package ID and Version. A NuGet component is a single.nupkgfile containing metadata.

npm

Nexus Repository identifies npm components by Package ID and Version (e.g., ramda : 0.28.0). An npm component is typically a single.tgzfile. Nexus Repository extracts metadata (like package.json) for indexing and browsing purposes, but it doesn’t store that metadata as a separate asset or count it toward component totals.

PyPI (Python)

Nexus Repository identifies a PyPI component by Name, Version, Qualifier (optional and not typically used for PyPI), and Extension. For example, MarkupSafe : 1.1.0 : : whl would represent a single PyPI component. A single PyPI component is typically one primary file (usually either .whl or .tar.gz). If the package is signed, there may also be one corresponding .asc file (GPG signature). Nexus Repository stores this as an additional asset but does not count it as a separate component.

P2 (Eclipse Plugins)

Nexus Repository identifies P2 components based on plugin or feature JAR files. A single P2 component consists of one.jarfile (e.g., org.example.plugin_1.0.0.jar). Nexus Repository does not count shared metadata files like content.xml and artifacts.xml toward component totals.

Raw

Nexus Repository treats every file as a separate component in Raw repositories. There is no grouping or metadata association.

RubyGems

Nexus Repository uses Name and Version to identify RubyGems components. A RubyGems component is a.gemfile with code and metadata.

Yum (RPM)

A Yum component in Nexus Repository is an.rpmfile that includes metadata for dependencies and versioning.

Search results

No results found