# 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](https://help.sonatype.com/en/usage-metrics.html "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](https://help.sonatype.com/en/usage-metrics.html "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.

## Search results

No results found