3

我正在我的笔记本电脑上开发几个 mavenised 项目，并定期推送到 github。我已经在云中建立了一个私有的 hudson 服务器，它轮询 git 存储库以获取更新，从而执行构建 - 到目前为止一切都很好。

不幸的是，当我在笔记本电脑上执行“mvn release:prepare”以执行发布（比如“1.5”）时，发生的两个提交（将 1.5-SNAPSHOT 更改为 1.5，然后将 1.5 更改为 1.6-SNAPSHOT）被推送到我的 git 存储库——Hudson 显然构建了最新版本，即 1.6-SNAPSHOT——并且完全忽略了 1.5 版本。

没关系，但是项目相互依赖，我想在我的 poms.xml 中声明非快照版本。但是，当项目 B 依赖于项目 A 的 1.5 版本时，在 Hudson 盒子上的 hudson 用户的本地 maven 存储库中找不到它——因为它从未被构建过——因此项目 B 的构建失败。

如果我能让 Hudson 更聪明一点，那就太好了，当它看到一个 maven 发布版本飞过时，会强制构建和安装该特定版本，然后再继续构建稍后的快照提交。

我一直在查看 Hudson 插件，尤其是“M2 Release Plugin”：

http://wiki.hudson-ci.org//display/HUDSON/M2+Release+Plugin

-但是，该插件似乎更倾向于手动选择要升级到一些更官方的 Maven 存储库的构建，而不是强制 Hudson 自动构建和安装它遇到的每个发布构建。

更新：我的一些基本要求让我重新思考我想要在这里实现的目标 - 很抱歉没有早点表达它们：

  • 大多数项目都是开源的或打算最终开放，我希望任何人都能够对git clone任何单个项目，签出发布标签，并在mvn install不需要任何其他 repo 的依赖项但 maven central 的情况下进行操作。
  • 为了获得一致的结果（通过我的笔记本电脑、hudson 服务器和其他人的结帐），这显然表明我倾向于在我的 pom 中声明非快照依赖项（至少对于发布版本）。
  • 这使我走上了尝试让 Hudson 在它们呼啸而过时“安装”发布工件的道路上，这样以后，当 Hudson 构建项目 B 找不到项目 A 的发布版本时，它就不会失败（这就是这个问题来自）

此外：

  • 我使用 sonotype 出色的 oss 托管，它需要 GPG 签名——而且我不想将我的 GPG 密钥存储在我无法拿在手中的任何硬件上 :)——所以将它安装在云中的 Hudson 服务器上是不是一个选择。
  • 在精神上，让 Hudson 服务器发布版本对我来说有点陌生——我真的只是想要它用于 CI。
4

3 回答 3

2

您现在需要的是实际执行发布。引用Maven - 使用发布插件的指南：

执行发布

该插件将提取与当前版本相关的文件修订。Maven 会将版本化的项目源代码编译、测试和打包成一个工件。最终的可交付成果将被发布到适当的 Maven 存储库中。

release:perform目标将：

  1. 提取在新标签名称下版本化的文件修订。
  2. 在提取的项目实例上执行 maven 构建生命周期。
  3. 将版本化的工件部署到适当的本地和远程存储库。

参考

于 2010-10-19T21:06:02.267 回答
0

我已经更新了我的问题描述，以提及我在我的 pom 中声明非快照依赖项的偏好（至少对于发布版本），以便获得一致的结果（在我的笔记本电脑、hudson 服务器和其他人的结帐中） -我真的希望其他人能够检查我的代码，并在寻找不可知的快照依赖项方面零烦恼。

它想在我的依赖项中使用非快照版本导致了这个问题——Hudson 的正常行为并没有使使用“发布”版本变得容易，至少不需要等待依赖项的发布版本循环到 maven Central。

但是，我已经决定，如果我想忠实于我的基本要求——人们可以轻松地签出和构建我的代码——那么这就是我必须做的：即等待 maven Central 同步。

我只想让自己坚持发布版本（否则我永远不会完成任何事情！），因此会很高兴地使用快照部门进行开发 - 直到我真正想要发布版本，此时我希望所有部门都能在 maven Central 中正常使用。

直到最近我才知道有任何方法可以强制执行此操作，但更多的谷歌搜索发现了我的“强制执行器”插件：

http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html

- 将“onlyWhenRelease”标志设置为true，看起来它应该完美地执行我想做的事情。

然后回答我最初的标题问题（'如何让 Hudson 自动构建和安装发布工件，而不仅仅是快照？'），我的答案是：

  1. 似乎没有完全简单的方法可以让 Hudson 做到这一点（没有 Hudson 的副作用，它还尝试在它检测到的每次签入时进行“释放”，这可能需要额外的“配置文件”配置来停止实际的正常操作发布，例如 GPG 签名）
  2. 不要那样做。
于 2010-10-21T23:28:25.123 回答
0

您可以指定用于确定构建是在本地还是远程部署的配置文件：

<project>
    <profile>
        <id>local-deploy</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <distributionManagement>
            <repository>
                <id>local-repo</id>
                <name>My Local Repo</name>
                <url>file://my/local/repo/dir</url>
            </repository>
        </distributionManagement>
    </profile>
    <profile>
        <id>remote-deploy</id>
        <activation>
            <activeByDefault>false</activeByDefault>
            <property>
                <name>remote.repo.url</name>    
            </property>
        </activation>

        <distributionManagement>
            <repository>
                <id>remote-repo</id>
                <name>My Remote Repo</name>
                <url>${remote.repo.url}</url>
            </repository>
        </distributionManagement>
    </profile>
</project>

然后您可以安全地运行release:perform目标，并且通过传入 remote.repo.url 的值，您还可以选择远程部署。

于 2010-10-21T05:55:12.133 回答