Maven Snapshot Repository vs Release Repository

1. Overview

In this tutorial, we’ll explain the differences between Maven snapshot and release repositories.

2. Maven Repositories

A Maven repository holds a collection of pre-compiled artifacts that we can use in our application as dependencies. With traditional Java applications, these are usually .jar files.

Generally, there are two types of repositories: local and remote.

A local repository is the repository Maven creates on the computer it is building on. It is usually located under the $HOME/.m2/repository directory.

When we build an application, Maven will search for the dependency in our local repository. If a certain dependency isn’t found, Maven will search for it in the remote repositories (defined inside the settings.xml or pom.xml files). Moreover, it will copy the dependency to our local repository for future use.

A remote repository is an external repository that contains artifacts. Once Maven has downloaded an artifact from the remote repository, it will prefer to look for the artifact in the local repository to limit artifact downloads.

Additionally, we can differentiate repositories based on the artifact types between snapshot and release repositories.

3. Snapshot Repository

The snapshot repository is a repository used for incremental, unreleased artifact versions.

A snapshot version is a version that has not yet been released. The general idea is to have a snapshot version before the released version. It allows us to deploy the same transient version incrementally, without requiring projects to upgrade the artifact version they’re consuming. Those projects can use the same version to get an updated snapshot version.

For instance, before releasing version 1.0.0, we can have its snapshot version. The snapshot version has a SNAPSHOT suffix after the version (for example, 1.0.0-SNAPSHOT).

3.1. Deploy an Artifact

Continuous development commonly uses snapshot versioning. With the snapshot version, we can deploy an artifact whose number consists of a timestamp and build number.

Let’s assume we have a project under development with a SNAPSHOT version:

<groupId>com.baeldung</groupId>
<artifactId>maven-snapshot-repository</artifactId>
<version>1.0.0-SNAPSHOT</version>

We’re going to deploy the project to a self-hosted Nexus repository.

Firstly, let’s define the publishing repository information where we want to deploy the artifact. We can use the distribution management plugin:

<distributionManagement>
    <snapshotRepository>
        <id>nexus</id>
        <name>nexus-snapshot</name>
        <url>http://localhost:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Further, we’ll deploy our project using the mvn deploy command.

After the deployment, the actual artifact version will contain a timestamp value instead of the SNAPSHOT value. For instance, when we deploy 1.0.0-SNAPSHOT, the actual value will contain the current timestamp and the build number (for example, 1.0.0-20220709.063105-3).

The timestamp value is calculated during the artifact deployment. Maven generates the checksum and uploads the artifact’s files with the same timestamp.

The maven-metadata.xml file holds precise information about the snapshot version and its link to the latest timestamp value:

<metadata modelVersion="1.1.0">
    <groupId>com.baeldung</groupId>
    <artifactId>maven-snapshot-repository</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <versioning>
        <snapshot>
            <timestamp>20220709.063105</timestamp>
            <buildNumber>3</buildNumber>
        </snapshot>
        <lastUpdated>20220709063105</lastUpdated>
        <snapshotVersions>
            <snapshotVersion>
                <extension>jar</extension>
                <value>1.0.0-20220709.063105-3</value>
                <updated>20220709063105</updated>
            </snapshotVersion>
            <snapshotVersion>
                <extension>pom</extension>
                <value>1.0.0-20220709.063105-3</value>
                <updated>20220709063105</updated>
            </snapshotVersion>
        </snapshotVersions>
    </versioning>
</metadata>

Metadata files help manage translation from the snapshot version to the timestamp value.

Every time we deploy the project under the same snapshot version, Maven will generate the version containing the new timestamp value and the new build number.

3.2. Download an Artifact

Before downloading the snapshot artifact, Maven downloads its associated maven-metadata.xml file. That way, Maven can check if there’s a newer version, based on the timestamp value and build number.

The retrieval of such an artifact can still use the SNAPSHOT version.

To download the artifact from the repository, firstly, we’d need to define a dependencies repository:

<repositories>
    <repository>
        <id>nexus</id>
        <name>nexus-snapshot</name>
        <url>http://localhost:8081/repository/maven-snapshots/</url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <releases>
            <enabled>false</enabled>
        </releases>
    </repository>
</repositories>

Snapshot versions are not enabled by default. We need to enable them manually:

<snapshots>
    <enabled>true</enabled>
</snapshots>

By enabling snapshots, we can define how often we’d like to check for a newer version of the SNAPSHOT artifacts. However, the default update policy is set to once per day. We can override this behavior by setting a different update policy:

<snapshots>
    <enabled>true</enabled>
    <updatePolicy>always</updatePolicy>
</snapshots>

There are four different values we can place inside the updatePolicy element:

• always — check for a newer version every time
• daily (default value) — check for a newer version once a day
• interval:mm — check for a newer version based on an interval set in minutes
• never — never try to get a newer version (compared to the one we already have locally)

Additionally, instead of defining the updatePolicy, we can force an update of all snapshot artifacts by passing the -U argument in the command:

mvn install -U

Furthermore, the dependency will not be re-downloaded if it has already been downloaded and the checksum is the same as the one we already have in our local repository.

Next, we can add a snapshot version of an artifact to our project:

<dependencies>
    <dependency>
        <groupId>com.baeldung</groupId>
        <artifactId>maven-snapshot-repository</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
</dependencies>

Using a snapshot version during the development phase can prevent having multiple versions of the artifact. We can use the same SNAPSHOT version whose build will contain the snapshot of our code at a given time.

4. Release Repository

The release repository contains the final versions (releases) of artifacts. Simply put, a release artifact stands for an artifact whose content should not be modified.

Release repositories are enabled by default for all repositories defined in our settings.xml or pom.xml files.

4.1. Deploy an Artifact

Now, let’s deploy the project in the local Nexus repository. Let’s assume we’ve finished with the development and are ready to release the project:

<groupId>com.baeldung</groupId>
<artifactId>maven-release-repository</artifactId>
<version>1.0.0</version>

Let’s define the release repository inside the distribution manager:

<distributionManagement>
    <repository>
        <id>nexus</id>
        <name>nexus-release</name>
        <url>http://localhost:8081/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
        <id>nexus</id>
        <name>nexus-snapshot</name>
        <url>http://localhost:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Once we remove the word SNAPSHOT from the project version, the release repository will be chosen automatically instead of the snapshot repository during the deployment.

Furthermore, if we want to redeploy the artifact under the same version, we may get an error: “Repository does not allow updating assets”. Once we deploy the released artifact version, we cannot change its content. Therefore, to resolve the problem, we’d need to simply release the next version.

4.2. Download an Artifact

Maven defaults to looking for components from the Maven Central Repository. This repository uses a release version policy by default.

Release repositories will only resolve released artifacts. In other words, it should contain only published artifact versions whose content should not change in the future.

If we want to download the released artifact, we’d need to define the repository:

<repository>
    <id>nexus</id>
    <name>nexus-release</name>
    <url>http://localhost:8081/repository/maven-releases/</url>
</repository>

Finally, let’s simply add the released version to our project:

<dependencies>
    <dependency>
        <groupId>com.baeldung</groupId>
        <artifactId>maven-release-repository</artifactId>
        <version>1.0.0</version>
    </dependency>
</dependencies>

5. Conclusion

In this tutorial, we learned the differences between Maven snapshot and release repositories. To sum up, we should use the snapshot repositories for projects that are still under development and release repositories for projects that are ready for production. As always, the source code for the examples is available over on GitHub.