Skip to main content

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 .deb package 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 .zip archive and its bower.json file.

Cargo

A single Cargo component is typically one .crate file.

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.gz file.

Nexus Repository identifies CocoaPods components by Name and Version (e.g., libpng : 1.4.9).

Composer

A Composer component is typically one .zip file.

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:

  • One or more .tar.gz archives (e.g., for binary packages or recipe sources)

  • Associated metadata files (like conanmanifest.txt, conaninfo.txt, and metadata.json)

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:

  • If you push three Docker tags and each tag references a unique manifest, Nexus Repository counts that as three components even if the layers are reused.

  • If you push three Docker tags that all point to the same manifest, Nexus Repository counts that as one component.

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 .tgz Helm 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:

  • Repository ID: hauson-fan/RagRetriever

  • Model: pytorch_model

  • Version: 4404c42d94447ab738eda599e4632b42a4c47a80

  • Extension: bin

  • Format: pytorch

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 .nupkg file 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 .tgz file. 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 .jar file (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 .gem file with code and metadata.

Yum (RPM)

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