What exactly is a Maven Snapshot and why do we nee

问题:

I am a bit confused about the meaning of a Maven Snapshot and why we build one?

回答1:

A snapshot version in Maven is one that has not been released.

The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It\'s basically \"1.0 under development\". This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).

The difference between a \"real\" version and a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday or tomorrow.

Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.

回答2:

The three others answers provide you a good vision of what a -SNAPSHOT version is. I just wanted to add some information regarding the behavior of Maven when it finds a SNAPSHOT dependency.

When you build an application, Maven will search for dependencies in the local repository. If a stable version is not found there, it will search the remote repositories (defined in settings.xml or pom.xml) to retrieve this dependency. Then, it will copy it into the local repository, to make it available for the next builds.

For example, a foo-1.0.jar library is considered as a stable version, and if Maven finds it in the local repository, it will use this one for the current build.

Now, if you need a foo-1.0-SNAPSHOT.jar library, Maven will know that this version is not stable and is subject to changes. That\'s why Maven will try to find a newer version in the remote repositories, even if a version of this library is found on the local repository. However, this check is made only once per day. That means that if you have a foo-1.0-20110506.110000-1.jar (i.e. this library has been generated on 2011/05/06 at 11:00:00) in your local repository, and if you run the Maven build again the same day, Maven will not check the repositories for a newer version.

Maven provides you a way to can change this update policy in your repository definition:

<repository>
    <id>foo-repository</id>
    <url>...</url>
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>XXX</updatePolicy>
    </snapshots>
</repository>

where XXX can be:

• always: Maven will check for a newer version on every build;
• daily, the default value;
• interval:XXX: an interval in minutes (XXX)
• never: Maven will never try to retrieve another version. It will do that only if it doesn\'t exist locally. With the configuration, SNAPSHOT version will be handled as the stable libraries.

(model of the settings.xml can be found here)

回答3:

The \"SNAPSHOT\" term means that the build is a snapshot of your code at a given time.

It usually means that this version is still under heavy development.

When the code is ready and it is time to release it, you will want to change the version listed in the POM. Then instead of having a \"SNAPSHOT\" you would use a label like \"1.0\".

For some help with versioning, check out the Semantic Versioning specification.

回答4:

A \"release\" is the final build for a version which does not change.

A \"snapshot\" is a build which can be replaced by another build which has the same name. It is implies the build could change at any time and is still under active development.

You have different artifacts for different builds based on the same code. E.g. you might have one with debugging and one without. One for Java 5.0 and one for Java 6. Generally its simpler to have one build which does everything you need. ;)

回答5:

Maven versions can contain a string literal \"SNAPSHOT\" to signify that a project is currently under active development.

For example, if your project has a version of “1.0-SNAPSHOT” and you deploy this project’s artifacts to a Maven repository, Maven would expand this version to “1.0-20080207-230803-1” if you were to deploy a release at 11:08 PM on February 7th, 2008 UTC. In other words, when you deploy a snapshot, you are not making a release of a software component; you are releasing a snapshot of a component at a specific time.

So mainly snapshot versions are used for projects under active development. If your project depends on a software component that is under active development, you can depend on a snapshot release, and Maven will periodically attempt to download the latest snapshot from a repository when you run a build. Similarly, if the next release of your system is going to have a version “1.8,” your project would have a “1.8-SNAPSHOT” version until it was formally released.

For example , the following dependency would always download the latest 1.8 development JAR of spring:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring</artifactId>
        <version>1.8-SNAPSHOT”</version>
    </dependency>

Maven

An example of maven release process

回答6:

This is how a snapshot looks like for a repository and in this case is not enabled, which means that the repository referred in here is stable and there\'s no need for updates.

<project>
    ...
    <repositories>
        <repository>
            <id>lds-main</id>
            <name>LDS Main Repo</name>
            <url>http://code.lds.org/nexus/content/groups/main-repo</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>
</project>

Another case would be for:

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

which means that Maven will look for updates for this repository. You can also specify an interval for the updates with tag.

回答7:

usually in maven we have two types of builds 1)Snapshot builds 2)Release builds

1. snapshot builds:SNAPSHOT is the special version that indicate current deployment copy not like a regular version, maven checks the version for every build in the remote repository so the snapshot builds are nothing but maintenance builds.

2. Release builds:Release means removing the SNAPSHOT at the version for the build, these are the regular build versions.

回答8:

I\'d like to make a point about terminology. The other answers gave good explanations about what a \"snapshot\" version is in the context of Maven. But does it follow that a non-snapshot version should be termed a \"release\" version?

There is some tension between the semantic versioning idea of a \"release\" version, which would seem to be any version that does not have a qualifier such as -SNAPSHOT but also does not have a qualifier such as -beta.4; and Maven\'s idea idea of a \"release\" version, which only seems to include the absence of -SNAPSHOT.

In other words, there is a semantic ambiguity of whether \"release\" means \"we can release it to Maven Central\" or \"the software is in its final release to the public\". We could consider -beta.4 to be a \"release\" version if we release it to the public, but it\'s not a \"final release\". Semantic versioning clearly says that something like -beta.4 is a \"pre-release\" version, so it wouldn\'t make sense for it to be called a \"release\" version, even without -SNAPSHOT. In fact by definition even -rc.5 is a release candidate, not an actual release, even though we may allow public access for testing.

So Maven notwithstanding, in my opinion it seems more appropriate only to call a \"release\" version one that doesn\'t have any qualifier at all, not even -beta.4. Perhaps a better name for a Maven non-snapshot version would be a \"stable\" version (inspired by another answer). Thus we would have:

• 1.2.3-beta.4-SNAPSHOT: A snapshot version of a pre-release version.
• 1.2.3-SNAPSHOT: A snapshot version of a release version.
• 1.2.3-beta.4: A stable version of a pre-release version.
• 1.2.3: A release version (which is a stable, non-snapshot version, obviously).