Type-Specific Basic Settings
Repositories may have additional Basic settings depending on the Package Type.
Maven, Gradle, Ivy and SBT Repositories
Checking the Checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how Artifactory behaves when a client checksum for a remote resource is missing or conflicts with the locally calculated checksum.
There are four options:
- Generate if absent (default): Artifactory attempts to retrieve the remote checksum, If it is not found, Artifactory will automatically generate one and fetch the artifact.
If the remote checksum does not match the locally calculated checksum, the artifact will not be cached and the download will fail.
- Fail: If the remote checksum does not mach the locally calculated checksum, or is not found, the artifact will not be cached and the download will fail.
- Ignore and generate: Artifactory ignores the remote checksum and only uses the locally generated one. As a result, remote artifact retrieval never fails, however integrity of the retrieved artifact may be compromised.
- Ignore and Pass-thru: Artifactory stores and passes through all remote checksums (even if they do not match the locally generated one). If a remote checksum is not found, Artifactory generates one locally. As a result, remote resource retrieval never fails, however integrity of the retrieved artifact may be compromised, and client side checksum validation (as performed by Maven, for example) will fail.
Max Unique Snapshots
|Please refer to Max Unique Snapshots under Local Repositories.|
Eagerly Fetch Jars
|When set, if a POM is requested, Artifactory attempts to fetch the corresponding jar in the background. This will accelerate first access time to the jar when it is subsequently requested.|
Suppress POM Consistency
|By default, Artifactory keeps your repositories healthy by refusing POMs with incorrect coordinates (path). If the |
groupId:artifactId:version information inside the POM does not match the deployed path, Artifactory rejects the deployment with a "409 Conflict" error.
You can disable this behavior by setting the Suppress POM Consistency checkbox.
Eagerly Fetch Sources
|When set, if a binaries jar is requested, Artifactory attempts to fetch the corresponding source jar in the background. This will accelerate first access time to the source jar when it is subsequently requested.|
|Please refer to Handle Releases under Local Repositories.|
|Please refer to Handle Snapshots under Local Repositories.|
Other Repository Types
For other type-specific repository configuration, please refer to the specific repository page under Artifactory Pro.
Handling Offline Scenarios
Artifactory supports offline repository management at two levels:
- Single Repository: One or more specific remote repositories need to be offline.
- Global: The whole organization is disconnected from remote repositories
Single Repository Offline
If a remote repository goes offline for any reason, Artifactory can be configured to ignore it by setting the Offline checkbox. In this case, only artifacts from this repository that are already present in the cache are used. No further attempt will be made to fetch remote artifacts.
Global Offline Mode
This is common in organizations that require a separate, secured network and are disconnected from the rest of the world (for example, military or financial institutions) .
In this case, remote repositories serve as caches only and do not proxy remote artifacts.
You can enable Global Offline Mode by setting the corresponding checkbox in the Admin tab under Configuration | General.
Browsing Remote Repositories
In some cases, the remote resource that Artifactory proxy's supports remote browsing. In these cases, you can browse the contents of these repositories directly from the Artifactory UI.
For example, JCenter and Maven Central support remote repository browsing, however, Docker Hub does not. In the example below, Artifactory is showing the contents of JCenter.