我目前有大量项目具有复杂的依赖结构，由50多名开发人员使用Maven 2/3与Nexus和Jenkins共同开发。我们快速开发，而且更常见的是我们不构建和部署具有SNAPSHOT依赖关系的版本。大多数情况下，在我们必须部署之前，我们不能等待一个或另一个团队构建发布版本。由于这个原因，我们遇到了许多问题，包括错误和在制品进入生产，并且不知道这些快照中有哪些变化。
我要做的是消除SNAPSHOTS并使用versions-maven-plugin转移到自动发行版并实现发布暂存策略。
这就是问题所在。对于开发人员和CI构建，需要将其配置为解析“暂存”和“发布”的依赖关系，并仅发布到“暂存”。然后，我们希望能够“推广”构建为发布版本，重新构建它以解决“发布”中的依赖关系并发布到“发布”（最初这将是手动促销，但我们也可能希望自动执行此操作） 。这一切听起来都合理吗？
我不想使用maven-release-plugin，因为我们之前尝试使用它，我们不喜欢它自动修改pom并在我们的scm中进行更改，从而触发更多构建。
另外，有没有办法告诉maven使用一个存储库进行解析而另一个存储库发布到？我可以用gradle做这个吗？
对此有任何意见/想法将不胜感激。
答案 0 :(得分：3)
这听起来很像我的构建系统。
我使用gradle和2个独立的nexus存储库（两个＆＃34;发布＆＃34;存储库，1个staging和1个final）执行此操作。构建具有目标成熟度的概念，并使用它来计算版本号（使用语义版本控制），因此RC构建产生类似1.0.0-rc1的版本，最终构建产生类似1.0.0的版本。然后我们以不同的方式标记测试（testng组，黄瓜标签等），以便不同的测试片段在不同的时间运行。构建根据目标成熟度决定依赖或发布哪些存储库，因此可以确保仅消耗足够成熟的人工制品。
这被配置为通过teamcity构建链自动运行，因此在某些核心库中的提交会在必要时通过下游构建和集成测试/部署（通过rundeck通过其java api通过一组gradle任务）进行。 / p>
Gradle发布和解析存储库是单独配置的，因此可以有所不同。同样可以在maven中完成。
例如，给定像
这样的依赖图corelib - ＆gt; mylib - ＆gt; myapp
每件事都会有一组与它们相关的测试标记为beta或rc。目的是产生RC的构建是通过beta测试的构建（即如果你通过beta，那么你已经成熟到足以成为RC）＆amp;该构建是快速完成的构建（例如仅进行单元测试），而rc测试（产生最终构建）可能会进行一些集成测试或一些长时间运行的测试。这个定义是我们自己的，完全是任意的，你可以做出任何你喜欢的区别。只有在产品具有一定的置信度后，我们才会基于应用越来越严格和/或持久的测试。
然后我们设置一个构建链，以便rc构建依赖于上游rc构建，最终构建依赖于上游最终构建和您自己的rc构建
即
--> mylib final --
/ \
mylib rc -- --> myapp final
\ /
--> myapp rc -----
等等。在这个例子中，流程是
每个点的版本号都是通过查询源控件来计算的
依赖于我们自己的人工制品，是动态的（例如1.0。+常春藤术语），major.minor静态设置（在源代码控制中），构建留下来生成补丁和候选数字本身，即myapp 1.0将取决于mylib 1.0。+。拥有2个独立的存储库作为过滤机制，而不是必须深入研究gradle / ivy中的分辨率逻辑来过滤掉我们不想要的那些，这样的IMO要简单得多。
答案 1 :(得分：2)
查看maven-version-plugin，特别是锁定/解锁快照目标。它们可以帮助识别程序集正在使用哪些依赖项，并且可能对您来说足够了。
如果没有，是的 - maven可以使用staging repositories，但是如果您想要播放的任何内容也被拉到本地开发者库中，则可能会导致混淆。
我们现在用来解决类似问题的是'脚本'，有点等同于maven-release-plugin（它实际上称之为某些操作），以及一个笨拙的版本控制方案：我们的开发分支保持1.2- SNAPSHOT，但我们发布/发布的版本使用不同的版本控制方案（1.2.3,1.2.4）。我们的脚本标签也是git。
答案 2 :(得分：1)
我建议不要使用maven release插件而不要使用快照。 看here以快速而干净的方式释放。