Overview
This section covers the controls that are specifics to local repositories.
Centrally Controlled Maven Unique Snapshot Policy
One of the unique features of Artifactory is you can gain centralized control on how snapshots are be deployed into a repository, regardless of end user-specific settings. This can guarantee standardized format for deployed snapshots within your organization.
You can choose between:
- Non-unique snapshots.
- Unique snapshots - with unique time-stamp and build number suffix.
- Deployer-respecting behavior - Artifactory will respect the user snapshot policy, i.e. act as a standard, non-smart, repository.
 | Maven 3 Only Supports Unique Snapshots
Maven 3 has, unfortunately, dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository that is using non-unique snapshot, it is recommended to change its Maven snapshot policy to 'Unique' and to remove any previously deployed snapshot 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. It is advised to have the artifact itself 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. |
Cleaning-up Unique Snapshots
Putting aside the question of usefulness in using unique snapshots (see the section above), you can tell 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 will not be available and will return 404 (not found). If the client has sent a
checksum that conflicts with the one calculated on the server a 409 (conflict) will be
returned until a valid checksum is deployed.
- Trust server generated checksums - Do not verify against checksums sent by clients
and trust the ones store server's locally calculated checksums. An uploaded artifact
will be available for consumption immediately, but integrity might be compromised.
Local Repositories