Local Repositories

Overview

Local repositories are physical, locally-managed repositories into which you can deploy artifacts. Using local repositories, Artifactory gives you a central location to store your internal binaries. Through repository replication, you can even share binaries with teams that are located in remote locations.

Artifacts in a local repository can be accessed directly using the following URL:

http://<host>:<port>/artifactory/<local-repository-name>/<artifact-path>

Configuring a Local Repository

To configure a local repository, in the Administration module, go to Repositories | Repositories select the Local tab, and click Add Repository.

Common Basic Settings

The following are fully described in the Common Settings page.

Package Type
Repository Key
Public Description
Internal Notes
Includes and Excludes Pattern
Max Unique Snapshots
Handle Releases
Handle Snapshots

Type-Specific Basic Settings

Repositories may have additional Basic settings depending on the Package Type.

Maven, Gradle, Ivy and SBT Repositories

Field	Description
Checksum Policy	Checking the Checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum. There are two options: Verify against client checksums (default) - If a client has not sent a valid checksum for a deployed artifact then Artifactory will return a 404 (not found) error to a client trying to access that checksum. If the client has sent a checksum, but it conflicts with the one calculated on the server then Artifactory will return a 409 (conflict) error until a valid checksum is deployed. Trust server generated checksums - Artifactory will not verify checksums sent by clients and will trust the server's locally calculated checksums. An uploaded artifact is immediately available for use, but integrity might be compromised.
Maven Snapshot Version Behavior	Artifactory supports centralized control of how snapshots are deployed into a repository, regardless of end user-specific settings. This can be used to guarantee a standardized format for deployed snapshots within your organization. There are three options: Unique: Uses a unique, time-based version number. Nonunique: Uses the default self-overriding naming pattern: `artifactID-version-SNAPSHOT.type` Deployer: Uses the format sent by the deployer as is. Deployer parameter option Metadata will not be generated when selecting the Deployer option. This option should not be used when setting up replication, since each Artifactory instance will need to generate its metadata locally. Maven 3 Only Supports Unique Snapshots Maven 3 has dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository using non-unique snapshots, we recommend that you change your Maven snapshot policy to 'Unique' and remove any previously deployed snapshots from this repository. The unique snapshot name generated by the Maven client on deployment cannot help in identifying the source control changes from which the snapshot was built and has no relation to the time sources were checked out. Therefore,we recommend that the artifact itself should embed the revision/tag (as part of its name or internally) for clear and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Build Integration support.
Suppress POM Consistency	When deploying an artifact to a repository, Artifactory verifies that the value set for `groupId:artifactId:version` in the POM is consistent with the deployed path. If there is a conflict between these then Artifactory will reject the deployment. You can disable this behavior by setting this checkbox.

Field

Description

Checksum Policy

Checking the Checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum.

There are two options:

Verify against client checksums (default) - If a client has not sent a valid checksum for a deployed artifact then Artifactory will return a 404 (not found) error to a client trying to access that checksum. If the client has sent a checksum, but it conflicts with the one calculated on the server then Artifactory will return a 409 (conflict) error until a valid checksum is deployed.
Trust server generated checksums - Artifactory will not verify checksums sent by clients and will trust the server's locally calculated checksums. An uploaded artifact is immediately available for use, but integrity might be compromised.

Maven Snapshot Version Behavior

Artifactory supports centralized control of how snapshots are deployed into a repository, regardless of end user-specific settings. This can be used to guarantee a standardized format for deployed snapshots within your organization. There are three options:

Unique: Uses a unique, time-based version number.
Nonunique: Uses the default self-overriding naming pattern: artifactID-version-SNAPSHOT.type
Deployer: Uses the format sent by the deployer as is.
Deployer parameter option
Metadata will not be generated when selecting the Deployer option. This option should not be used when setting up replication, since each Artifactory instance will need to generate its metadata locally.

Maven 3 Only Supports Unique Snapshots

Maven 3 has dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository using non-unique snapshots, we recommend that you change your Maven snapshot policy to 'Unique' and remove any previously deployed snapshots from this repository.

The unique snapshot name generated by the Maven client on deployment cannot help in identifying the source control changes from which the snapshot was built and has no relation to the time sources were checked out. Therefore,we recommend that the artifact itself should embed the revision/tag (as part of its name or internally) for clear and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Build Integration support.

Suppress POM Consistency

When deploying an artifact to a repository, Artifactory verifies that the value set for groupId:artifactId:version in the POM is consistent with the deployed path.

If there is a conflict between these then Artifactory will reject the deployment. You can disable this behavior by setting this checkbox.

Common Advanced Settings

Field	Description
Priority Resolution	Setting Priority Resolution takes precedence over the resolution order when resolving virtual repositories. Setting repositories with priority will cause metadata to be merged only from repositories set with this field. If a package is not found in those repositories, Artifactory will merge metadata from the repositories that have not been set with the Priority Resolution field. Applies to all repository types excluding Chef, CocoaPods, Debian, Git LFS, Opkg, Rust, Vagrant, and VCS repositories. For more information on package support for this feature, see the Artifactory Release Notes.Artifactory Release Information
Blacked out	If set, Artifactory ignores this repository when trying to resolve artifacts. The repository is also not available for download or deployment of artifacts.
Allow content browsing	When set, allows Artifactory users to browse the internal contents of archives (for example, browsing specific Javadoc files from within a Javadoc archive). When archive browsing is allowed, strict content moderation should be employed to ensure malicious users do not upload content that may compromise security (e.g. cross-site scripting attacks)
Enable CDN Download	Enables CDN Download requests to this repository will redirect the client to download the files directly from AWS CloudFront. Supported for Enterprise+ and Enterprise Licenses. For more information, see JFrog Cloud with CDN Distribution.JFrog Cloud with CDN Distribution

Replications

The Replications tab lets you define and edit replication settings for the repository. For details, please refer to Repository Replication.