我正在设置 Hudson 以使用批处理任务插件向我们的内部存储库执行 maven 发布。我正在通过：
mvn --batch-mode release:prepare
mvn --batch-mode release:perform
我对人们使用的其他方法以及这些方法的优缺点很感兴趣。此外，人们遇到的任何问题。
【问题讨论】：
标签： maven-2 jenkins continuous-integration hudson release-management
出于几个原因，我倾向于总是手动发布。首先，如果您必须回滚，则可以回到原始发布位置并执行此操作会更容易。其次，因为您需要在流程中解决所有快照依赖项。
我们的开发过程要求我们将依赖项留在当前版本的当前版本之外，直到修复需要升级。这意味着如果我要发布 Nexus、Maven 等，那么我会看到快照，这意味着我必须先发布这些快照。这个过程实际上不可能自动化，因为它会根据自上次发布以来的变化而有所不同。
也就是说，我们有一台专门用于构建的机器（在 Sonatype 中它只是一个 vm）设置。这样做是为了保证不会发生可能会意外影响构建的环境更改（例如 jdk 更改）。它还使任何人都可以更轻松地了解发布过程，因为它随时准备就绪。
【讨论】：
最近，我注意到了一个 m2release 插件。看起来不错。虽然，我希望我的发布过程完全“无 pom-tweaking”。我的意思是我们必须提供 4 个输入参数来处理完整的发布：
前 2 个具有可接受的默认值。与错误修复版本数字碰撞的版本对我来说非常好。
数字 4 可以在 pom.xml 中指定。它不会改变。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagBase>https://example.com/svn/myProject/releases</tagBase>
</configuration>
</plugin>
这是第三个阻止我按一个按钮完全自动化发布的原因。默认的发布标签标签不会为我们做这件事，所以我们必须指定它：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tag>release-${pom.version}</tag>
<tagBase>https://example.com/svn/myProject/releases</tagBase>
</configuration>
</plugin>
现在，虽然这可能正是我所需要的，但我最终得到了一个带有 -SNAPSHOT 的 svn 标签。 :( 所以我必须在 Hudson 作业配置中传递 tag 参数。此外，我必须为我们制作的每个版本都更改它......这不是我所需要的。
所以，最后，在 hudson 中拥有一个 maven2 类型的项目 + m2release hudson 插件 + 正确配置的 maven 发布插件是我迄今为止看到的所有发布过程的母亲。虽然并不完美，但它为我节省了很多繁琐的工作。
JS.
【讨论】：
<tag>release-@{project.version}</tag> 更正确，否则它会被我的 Maven 的 SNAPSHOT 版本替换。
我总是手动触发发布，有明显的利弊:-)
【讨论】：
我们一直在尝试使用 Hudson Maven 发布插件，但我有点难以让它正确地记入发布，而不是将密码硬编码到我们的构建文件中。
【讨论】：