第一次遇到Maven时，您将遇到工件的神奇快照版本控制。人们通常会问的第一个问题是"这些‘effin-SNAPSHOTs’是什么？"嗯，这很容易。它们是工件的非正式快照，当您走向没有-SNAPSHOT的版本时。假设我们正在开发Überwizbang产品的2.5版本。好吧，在这种情况下，我们会给它2.5版本的快照…当我们准备好削减一个正式的alpha版本（即，我们认为有点稳定的快照），我们将创建一个2.5-alpha-1版本…或者我们将使用里程碑，削减2.5-m1。-快照只是另一个限定符，它让您知道这不是最终版本。Maven说任何带有限定符的东西都要在实际发布之前出现版本.As顺便说一句，这也许可以解释为什么有些组织（我在看你，特里比风格的Linux先生）在他们所有的发行版中都使用限定符…你可以看到-ALPHA-\uuux、-BETA-\uuuu、-CR-\uuuu（候选发行版）、-GA（实际发行版），-MR-\uuuuu（维护版本），CR在正式发布前经过精心选择…绝不会有不合格的版本释放了。没什么这种方法是错误的，只要你始终如一。当然，添加另一个点分隔的数字，并用它来表示维护版本也同样有效，而且副作用是当你有10个以上的维护版本时，你不需要开始给他们奇怪的版本号，例如1，2，3，…9，然后是91，广西大数据，92，93，…99，991，992，993等等，或者提前计划和预填充足够的0只是为了确保ASCII排序结果是数值排序maven treats-SNAPSHOT版本。Maven期望-快照会改变，反之，免费企业管理软件，非快照永远不会改变。结果是，一旦Maven在本地缓存（又称本地存储库）中缓存了2.5-alpha-1（不是-SNAPSHOT），它将永远不会刷新缓存。所以，如果你重复2.5-alpha-1几次直到你"做对了"……好吧，把第一个放进他们本地存储库的人只会有第一个旋转，而不是"真正的"2.5-alpha-1，也就是第三个旋转。什么时候不过，对于快照，Maven会定期检查更新。我听说你问多久一次…嗯，这取决于您在设置.xml默认值是daily，但是每个开发人员都可以选择任何适合的时间间隔他们。它不幸的是，存储库的XML模式对和重用了相同的结构，因为给一个未使用的子元素的副作用是迷惑用户[注意，它不是实际上没有使用，它控制Maven检查Maven更改的频率-元数据.xml文件夹，但是它仍然会引起用户的困惑]）所以发生的事情是你开始一个Maven构建，它做的第一件事就是检查你的快照依赖项是否在reactor之外（即，你当前要求Maven构建的模块列表）现在当你有一个非常大的项目，有很多开发人员，你有时会看到一种模式，开发人员组倾向于只在项目中的一小部分模块上工作。这可能发生在两种情况中的一种方法：整体über项目作为一个大项目发布砰。每个人"团队"开发人员一个接一个地发布组件，有时根据需要重新发布单独的组件，直到最终ulber project安装程序/分发模块准备好发布，并将各个组件捆绑在一起使用big-bang发行版，如果您的构建需要很长时间才能完成（即使跳过测试），或者某些模块需要特定的工具链，那么作为"方便"的方式开发人员可以配置一个CI服务器（比如Jenkins）来部署快照，这样如果我只处理一个模块，就不必构建所有的时间。和基于组件的发布，您可以配置一个CI服务器来部署每个组件的快照，这样下游团队就可以与上游更改集成，而不必等待上游团队削减下一个更改释放。输入不过，将军，我们需要记住，在引入-快照的部署时，我们不想强迫开发人员在sand上构建。这其中有三个因素相互作用地区：多久一次是否部署了-快照（由CI服务器控制…可能还有一些单独的开发人员在其他人被阻止等待更改（如果间隔太长而无法满足他们的需要）时手动推送快照）Maven多久配置一次以检查更新（由或者我不想知道开发人员如何在离线的基础上更新。所以我更喜欢从更新源代码管理开始我的一天，并在每次更新后进行完整的构建。我不希望-快照部署到远程存储库，因为现在，在子模块中工作时，如果我使用的依赖关系是我从SCM进行更新时本地构建的依赖关系，大数据公司，还是Maven从远程存储库下载的依赖关系。我很可能希望将我的设置为从不来防止这种情况发生不确定。那里是不是其他的开发者不介意在这样一个变化无常的沙子上工作……确实有些时候我的机器上没有完整的工具链，我不得不在这种情况下进行开发……但是如果你想要高效的开发人员，他们需要有能力控制他们的更新何时发生，并对可能发生的事情有把握改变了。定义快照部署策略这是您可以做的最重要的事情。让每个人都知道-快照将被部署，例如，每天格林尼治标准时间凌晨1点、每周日、每小时、每次提交时，或当Joe决定将新快照推送到存储库时。我不在乎你选什么政策。只需选择一项政策，让所有人都知道。关于我的：请考虑一下使用原子部署机制。定义快照保留策略（使使用时间戳快照的用户知道可以依赖它们多长时间）请考虑开发人员的时区。尽量确保部署在所有开发人员开始工作之前进行。最糟糕的情况是你正在开发一个特性，而你早上的工作已经进行了一半，新云，淘客单，Maven开始下载——快照和你现在正在处理的代码甚至因为其他地方的更改而无法编译……当你准备提交或合并回你的更改时，你想解决这些问题……你不想被打倒当你试图解决一个特定的问题。要么使用CI服务器以固定的速度部署快照，或者根据需要让开发人员推送快照。不要混在一起匹配。它可以说你永远不会部署快照。不需要部署-快照，只要：mvn clean install-über项目的DskipTests比较快（也就是说，它将在我做咖啡的时候完成），我不需要一些特定的工具链来构建über项目。例如，如果您需要VisualStudio来构建JNDI.dll和GCC来构建.so和…那么您可能需要部署CI服务器-SNAPSHOTsLet开发人员决定他们的不强制要求特定的，因为这将迫使开发人员动手。无论如何，您应该教育您的开发人员并推荐一个。只是不要把他们的设置.xml并强制他们使用特定的。为功能分支定义-SNAPSHOT策略是什么。持续时间超过一两天的功能分支确实需要自己的版本号，即使那只是"2.5-feature-blah-SNAPSHOT"。如果要为这些功能分支部署快照，您不希望两个不同的分支发生冲突，因此它们需要不同的版本数字。使用时间戳快照Maven的一个特性就是所谓的时间戳快照，在部署时，-SNAPSHOT替换为-年月日-n部署的时间戳。这可以解决特性分支的一些问题，特别是与版本Maven插件结合使用时，该插件的目标是"锁定"和"解锁"当前时间戳版本的快照依赖关系，从而消除了不确定性。这对特性很有帮助树枝。那些只是我的一些想法。希望你能发现它们对你有帮助。-斯蒂芬康诺利云蜂cloudbees.com斯蒂芬康诺利有近20年的软件开发经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。斯蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。在Twitter和他的博客上关注斯蒂芬。