CodeSoh documentation

Appearance

Snapshots ​

A snapshot version, such as 1.0-SNAPSHOT, holds many builds. Each deploy adds a build with its own timestamp, and clients resolve the newest one.

How a snapshot deploy works ​

Maven expands a snapshot version into a timestamped version before it uploads. A build of 1.0-SNAPSHOT is uploaded to a path like the following:

com/example/snap/1.0-SNAPSHOT/snap-1.0-20260913.101500-1.jar

The timestamp is yyyyMMdd.HHmmss in UTC, and the number after it is the build number, which starts at 1. Artifex records each build separately, and every build stays downloadable at its own path.

Deploying the same timestamped path twice is a conflict, not a replacement. The second deploy is refused with 409 Conflict and the message This snapshot build already exists. Deploy again to create a new build. Deploy again, and your client produces a new timestamp and build number.

What clients see ​

Artifex generates version-level metadata at GROUP/ARTIFACT/VERSION-SNAPSHOT/maven-metadata.xml. It names the newest build only:

  • timestamp and buildNumber of the newest build
  • one snapshotVersion entry for each file of that build, with its classifier, its extension, and the timestamped version to request

That's what makes a build resolve the newest snapshot. Older builds aren't advertised, but they're still served if a build asks for them by their exact path.

Before the first deploy of a snapshot version, the version-level metadata doesn't exist and a request for it answers 404 Not Found. That's what a Maven client expects.

At the artifact level, a snapshot version appears in the version list and can be the latest, but it's never the release.

Newest is decided by the timestamp first and the build number second, so a build that arrives late with an older timestamp doesn't take over.

Metadata that a client uploads ​

Maven uploads its own version-level metadata at the end of a snapshot deploy. Artifex generates its own from the builds it holds, and checks the upload for agreement. If the uploaded document names a build other than the newest deployed one, the upload is refused with 400 Bad Request and the message names the build in the document and the newest build that was deployed. Deploy the files before the metadata.

Repositories that take releases only ​

An administrator can refuse snapshots entirely.

To refuse them, follow these steps:

  1. Open the repository and go to Settings.
  2. Turn off Allow snapshots.
  3. Click Save changes.

Deploying a -SNAPSHOT version then answers 403 Forbidden with the message This repository doesn't accept snapshot versions. Files that were already deployed stay where they are.

A common arrangement is two repositories: one that allows snapshots for daily builds, and one that takes releases only.