我对Maven快照的含义有点困惑,为什么我们要构建一个?


“发行版”是一个没有更改的版本的最终版本。

“快照”是一个可以被具有相同名称的另一个构建所替换的构建。这意味着构建可以在任何时候更改,并且仍然处于积极的开发中。

对于基于相同代码的不同构建,您有不同的工件。例如,你可能有一个调试和一个没有。一个用于Java 5.0,一个用于Java 6。一般来说,一个版本能满足你所有的需求会更简单。;)


“快照”术语意味着构建是给定时间内代码的快照。

这通常意味着这个版本仍在大量开发中。

当代码准备好并且是时候发布它时,您将希望更改POM中列出的版本。然后,您将使用“1.0”这样的标签,而不是使用“SNAPSHOT”。

有关版本控制的帮助,请查看语义版本控制规范。


Maven中的快照版本是尚未发布的版本。

其思想是,在1.0发行版(或任何其他发行版)完成之前,存在1.0- snapshot。这个版本可能会变成1.0。它基本上是“正在开发的1.0版本”。这可能接近于真正的1.0发行版,或者相当远(例如,就在0.9发行版之后)。

“真实”版本和快照版本之间的区别是快照可能会得到更新。这意味着今天下载1.0-SNAPSHOT的文件可能与昨天或明天下载的文件不同。

通常,快照依赖关系应该只存在于开发过程中,没有发布版本(即没有非快照版本)应该依赖于快照版本。


其他三个答案让您对-SNAPSHOT版本有了一个很好的了解。我只是想添加一些关于Maven在发现SNAPSHOT依赖项时的行为的信息。

在构建应用程序时,Maven将在本地存储库中搜索依赖项。如果在那里没有找到稳定版本,它将搜索远程存储库(在settings.xml或pom.xml中定义)以检索此依赖项。然后,它将把它复制到本地存储库中,使其可用于下一个构建。

例如,foo-1.0.jar库被认为是一个稳定版本,如果Maven在本地存储库中找到它,它将在当前构建中使用这个库。

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为您提供了一种在存储库定义中更改此更新策略的方法:

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

其中XXX可以是:

always: Maven将在每次构建时检查更新的版本; 每日,默认值; interval:XXX:单位为分钟的间隔(XXX)。 never: Maven永远不会尝试检索其他版本。它只在本地不存在时才会这样做。通过配置,SNAPSHOT版本将作为稳定库处理。

(settings.xml的模型可以在这里找到)


这就是存储库的快照的样子,在本例中没有启用快照,这意味着这里引用的存储库是稳定的,不需要更新。

<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>

另一种情况是:

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

这意味着Maven将为这个存储库查找更新。您还可以使用标记指定更新间隔。


通常在maven中,我们有两种类型的构建 1)建立快照 2)制定版本发布

快照构建:快照是特殊版本,它指示当前部署副本,不像常规版本,maven检查远程存储库中的每个构建的版本 因此快照构建只是开发构建。 发布版本:发布意味着在版本中删除快照,这些是常规的构建版本。


Maven版本可以包含一个字符串文字“SNAPSHOT”,以表示项目目前正在积极开发中。

例如,如果您的项目有一个“1.0-SNAPSHOT”版本,并且您将这个项目的工件部署到Maven存储库, 如果您愿意,Maven会将这个版本扩展到“1.0-20080207-230803-1” 在UTC 2008年2月7日11:08 PM部署一个版本。换句话说,当你 部署一个快照,您不是在发布一个软件组件;你是 在特定时间释放组件的快照。

因此,快照版本主要用于正在积极开发的项目。 如果您的项目依赖于正在积极开发的软件组件, 您可以依赖快照发布,Maven将定期尝试 运行构建时从存储库下载最新快照。类似地,如果 您的系统的下一个发行版将有一个“1.8”版本,您的项目也会如此 “1.8-SNAPSHOT”版本,直到正式发布。

例如,下面的依赖项总是会下载最新的1.8版本的spring开发JAR:

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

Maven

maven发布过程的一个例子


我想谈谈术语。其他答案很好地解释了什么是Maven上下文中的“快照”版本。但是,非快照版本是否应该被称为“发布”版本呢?

在“发布”版本的语义版本控制思想之间存在一些紧张关系,“发布”版本似乎是任何没有-SNAPSHOT这样的限定符,但也没有-beta.4这样的限定符的版本;以及Maven的“发布”版本的想法,它似乎只包括没有-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.

因此,尽管Maven如此,在我看来,只将“发布”版本称为根本没有任何限定符(甚至没有-beta.4)的版本似乎更合适。对于Maven非快照版本来说,更好的名称可能是“稳定”版本(灵感来自另一个答案)。这样我们就有:

1.2.3-beta。4-SNAPSHOT:预发布版本的快照版本。 1.2.3-SNAPSHOT:发布版本的快照版本。 1.2.3-beta。4:预发布版本的稳定版本。 1.2.3:发布版本(显然是一个稳定的非快照版本)。


understanding the context of SDLC will help understand the difference between snapshot and the release. During the dev process developers all contribute their features to a baseline branch. At some point the lead thinks enough features have accumulated then he will cut a release branch from the baseline branch. Any builds prior to this time point are snapshots. Builds post to this point are releases. Be noted, release builds could change too before going to production if any defect spot during the release testing.


简单快照意味着它是一个不稳定的版本。

当版本包含快照,如1.0.0 -SNAPSHOT意味着它不是稳定的版本,并寻找远程存储库来解决依赖关系


快照仅仅意味着Maven将根据您的配置检查特定依赖项的最新更改。快照是不稳定的,因为它是在开发中,但如果在一个特殊的项目需要有最新的变化,你必须配置你的依赖版本为快照版本。这种情况发生在拥有多个产品的大型组织中,这些产品彼此密切相关。


顾名思义,快照指的是项目的状态及其在那个时刻的依赖关系。每当maven找到一个较新的项目SNAPSHOT时,它就下载并替换本地存储库中较旧的项目.jar文件。

快照版本用于正在进行开发的项目。如果您的项目依赖于正在积极开发的软件组件,那么您可以依赖于快照发布,并且当您运行构建时,Maven将定期尝试从存储库下载最新的快照。


A Maven SNAPSHOT is an artifact created by a Maven build and pretends to help developers in the software development cycle. A SNAPSHOT is an artifact (or project build result ) that is not pretended to be used anywhere, it's only a temporarily .jar, ear, ... created to test the build process or to test new requirements that are not yet ready to go to a production environment. After you are happy with the SNAPSHOT artifact quality, you can create a RELEASE artifact that can be used by other projects or can be deployed itself.

在你的项目中,你可以使用Maven的pom.xml文件中的version元素定义一个SNAPSHOT:

<groupId>example.project.maven</groupId>
<artifactId>MavenEclipseExample</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<description>Maven pom example</description>

如果你想更好地理解Maven,你也可以看看这些文章:

https://connected2know.com/programming/menu-maven-articles/


在开发阶段,Maven快照每天都会寻找更新的更高版本(如果在nexus存储库中可用),然后在本地下载它以备下一次构建。

您可以在存储库定义中设置四个选项

总是这样, 每日(默认), 间隔, 永远,

注意:在产品版本中,我们不应该依赖于快照版本。


SNAPSHOT值指的是沿着开发分支的“最新”代码,并不能保证代码是稳定的或不变的。相反,“发布”版本(任何不带SNAPSHOT后缀的版本值)中的代码是不变的。

换句话说,SNAPSHOT版本是最终“发布”版本之前的“开发”版本。SNAPSHOT比它的发行版“更老”。

在发布过程中,x.y-SNAPSHOT的一个版本更改为x.y。发布过程还将开发版本增加到x.(y+1)-SNAPSHOT。例如,版本1.0- snapshot发布为版本1.0,新的开发版本为版本1.1-SNAPSHOT。