Overview
This section covers the controls that are specific to local repositories.
| Field Name | Description |
|---|
| Public Description | Free text description of the repository. This description also appears when selecting the repository in the tree browser. |
| Internal Notes | Optional free text description about this repository. |
| Includes Pattern | Comma-separated list of artifact patterns to include when evaluating artifact requests, in the form of x/y/**/z/*. When used, only requests matching one the include patterns are served. By default all artifacts are included (**/*). |
| Excludes Pattern | Comma-separated list of artifact patterns to exclude when evaluating artifact requests, in the form of x/y/**/z/*.
By default no artifacts are excluded. |
| Repository Layout | Select the layout that the repository should use for storing and identifying modules. |
| Cheksum Policy | Checksum policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum (bad checksum). Checksum checking effectively verifies the integrity of the deployed resource. There are two options:
(1) Verify against client checksums (default) - Until a client has sent a valid checksum for a deployed artifact matching the server's locally calculated checksum, the artifact's checksum is not available and returns a 404 (not found) error. If the client has sent a checksum that conflicts with the one calculated on the server a 409 (conflict) is returned until a valid checksum is deployed. (2) Trust server generated checksums - Do not verify against checksums sent by clients and trust the server's locally calculated checksums. An uploaded artifact is available for consumption immediately, but integrity might be compromised. |
| Maven Snapshot Version Behavior | Whether to use time-based version numbers for the name of SNAPSHOTs, or to use a non-unique, self-overriding naming pattern of artifactId-version-SNAPSHOT.type (the default), or to respect the deployer settings coming from the Maven client. |
| Max Unique Snapshots | The maximum number of unique snapshots (of the same artifact) to store. Any number of snapshots above the max are automatically removed by age. A value of 0 (the default) indicates that there are no limits on the number of unique snapshots (thus no automatic cleanup). |
| Handle Releases | Whether the repository handles release artifacts. |
| Handle Snapshots | Whether the repository handles snapshot artifacts. |
| Blacked Out | Whether the repository is blacked-out. A blacked-out repository does not participate in artifact resolution, nor does its local cache. |
| Suppress POM Consistency Checks | Whether the repository should suppress POM Consistency Checks. |
| Allow Archive Browsing | Allow Unsafe Archive Content Browsing - Determines whether viewing archive content (e.g., Javadoc browsing) directly from Artifactory is allowed.
Allowing content browsing requires strict content moderation to ensure malicious users do not upload content that is used to compromise security. For example, to conduct cross-site scripting attacks. |
Centrally Controlled Maven Unique Snapshot Policy
Artifactory allows you centralized control of how snapshots are be deployed into a repository, regardless of end user-specific settings. This guarantees standardized format for deployed snapshots within your organization.
| Field Name | Description |
|---|
| Snapshot Version Behavior | The available options are: - Non-unique snapshots
- Unique snapshots - with unique time-stamp and build number suffix
- Deployer-respecting behavior - Artifactory respects the user snapshot policy, i.e. act as a standard, non-smart, repository
|
| Max Unique Snapshots | Maximum number of unique snapshots to be deployed |
Cleaning-up Unique Snapshots
You can configure Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique Snapshots value to the maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect on each new snapshot deployment.
Handling Deployed Client Checksums
Checksum policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum (bad checksum).
Checksum checking effectively verifies the integrity of the deployed resource.
The options are:
- Verify against client checksums (default) - Until a client has sent a valid checksum for a deployed artifact that matches the server's locally calculated checksum, the artifact is unavailable and returns a 404 (not found) error message. If the client has sent a checksum conflicting with the one calculated on the server, a 409 (conflict) error message is returned until a valid checksum is deployed.
- Trust server generated checksums - Do not verify against checksums sent by clients and trust the store server's locally calculated checksums. An uploaded artifact is unavailable for consumption immediately, but integrity might be compromised.
Pre-canned Repositories
Artifactory comes with a set of per-defined local repositories, which reflect binary management best practices.
| Repository Name | Purpose |
|---|
libs-release-local | Your code releases |
libs-snapshot-local | Your code snapshots |
ext-release-local | Manually deployed 3rd party libs (releases) |
ext-snapshot-local | Manually deployed 3rd party libs (shapshots) |
plugins-release-local | Your and 3rd party plugins (releases) |
plugins-snapshot-local | Your and 3rd party plugins (snapshots) |