Apache Maven Resolver

Apache Maven Artifact Resolver is a library designed for managing artifact repositories and performing dependency resolution. It provides the core logic for handling:

• Local and Remote Repositories: Specifying where artifacts are stored and retrieved.
• Developer Workspaces: Managing environments for development.
• Artifact Transports: Moving artifacts between locations.
• Artifact Resolution: The process of determining and fetching the required dependencies.

Note that the core library is intended to be extended by concrete repository implementations. For example, to work with standard Maven repositories, you should use the Maven Artifact Resolver Provider.

Resolver is an embeddable Java library designed for artifact resolution and deployment. It allows you to integrate Maven-like dependency resolution mechanisms into your own applications without embedding the entire Maven distribution or Plexus.

Key capabilities include:

• Fetching artifacts from remote repositories for local consumption.
• Publishing local artifacts to remote repositories.
• Providing a customizable framework for artifact resolution and deployment.
• Supporting multithreaded environments (unlike the stateful singletons found in standard Maven).

Note that Resolver Core is tool-agnostic and does not natively understand Maven repository formats. It relies on extensions to handle specific repository types.

The maven-resolver-transport-url is a lightweight, special transport implementation with limited HTTP capabilities. It is designed for applications running on Java 8+ that integrate the Maven Resolver strictly for consumption purposes (e.g., downloading artifacts).

It serves as a middle ground between the JDK transport (which requires Java 11+) and the heavyweight apache-httpclient transport, making it ideal for environments where minimizing dependencies and resource usage is a priority.

Important Limitation: This transport is not a fully functional transport. While it is highly effective for artifact consumption, it is not suitable for artifact deployment.

Remote Repository Filtering (RRF) is a feature in Maven Resolver that allows the resolver to filter artifacts by repository based on extensible criteria. Instead of the traditional "ordered loop" search (where Maven queries every repository in the effective POM until an artifact is found), RRF allows Maven to query only the repositories that are likely to contain the specific artifact.

Benefits:

• Faster builds: Reduces unnecessary queries to repositories that do not contain the artifact.
• Privacy/Reduced Leakage: Prevents "leaking" artifact requests to remote repository operators (e.g., querying Maven Central for internal artifacts).
• Build Stability: Avoids the need for "virtual" or "group" repositories in MRM (Maven Repository Managers), which can cause loss of artifact origin information and make projects un-buildable if the MRM is unavailable.

The Remote Included strategy allows Resolver to retrieve the expected checksum within the same HTTP response used to download the artifact. This is efficient as it requires only one HTTP request.

Requirements & Limitations:

• This strategy only works with transport-http. It is not supported by transport-wagon.
• You can enable or disable this behavior using the aether.connector.basic.includedChecksums configuration key.

Supported Header Variants: Resolver automatically detects several unstandardized X- headers used by different providers:

• Maven Central: x-checksum-sha1, x-checksum-md5
• Google Mirror of Maven Central: x-goog-meta-checksum-sha1, x-goog-meta-checksum-md5
• AWS S3: x-amz-meta-checksum-sha1, x-amz-meta-checksum-md5

Maven Resolver uses checksums (typically SHA-1 and MD5) located next to target files in repositories to verify the integrity of downloaded artifacts and metadata.

Important Security Note: Checksums are intended only for detecting transport errors and verifying integrity. They do not provide security, trust, or protection against man-in-the-middle or supply chain attacks. To ensure an artifact has not been tampered with, you must use digital signatures (e.g., via the Maven GPG Plugin).

Maven Resolver uses a Service Provider Interface (SPI) to manage checksum algorithms instead of exposing java.security.MessageDigest directly. This prevents the accidental addition of non-standard checksums while allowing controlled extensions.

The SPI currently supports the following four case-sensitive algorithms:

• MD5
• SHA-1
• SHA-256
• SHA-512

If you need to support a checksum algorithm not provided by Maven Resolver, you can extend the system by creating a new factory component for that algorithm and registering it via the SPI.

When multiple threads, processes, or hosts access the same local repository, concurrent read/write operations can lead to corrupted or incomplete data.

To prevent this, Maven Resolver provides a pluggable Named Locks API. Available implementations include:

• Multi-threaded: Locking within a single JVM (default).
• Multi-process: Using file system advisory locking.
• Multi-host: Using distributed locking via Hazelcast or Redisson (requires a cluster).

The deployment workflow in Maven Resolver follows a layered abstraction model:

1. RepositoryConnector: The high-level component (e.g., BasicRepositoryConnector) that manages the deployment logic.
2. RepositoryLayout: Responsible for determining the destination path. It uses methods like getLocation(Artifact, true) or getLocation(Metadata, true) to calculate the correct URL based on the repository type (e.g., Maven2RepositoryLayoutFactory for Maven 2 layouts).
3. Transporter: The low-level component that performs the actual I/O. It receives the location from the layout and executes the write/upload operation.