Eclipse Foundation 首次发布 Hudson

几周之前，Eclipse Foundation发布了著名的持续集成系统 Hudson 3.0 。Hudson 项目的根源可以追溯到两年前，当时从 Hudson分支出了Jenkins ，并且它本身被提议作为一个中立的托管组织加入Eclipse Foundation 。尽管在那之后，两个分支都继续发展至今，并且在分支之后还发布了Hudson 2.2.1，但此次的Hudson 3.0 才是真正意义上的首次发布。

Hudson 提供了两种获取方式：一个简单的 web 压缩包（仅包含核心特性）和一个打包的版本（包含若干有用的插件）。可以从 Maven Central 上获取，也可以从 Eclipse Foundation 网站上下载。

孵化项目所必须的清理工作是导致这次发布花费时间太长的原因之一。在 2011 年 5 月， InfoQ 提到：

Eclipse Foundation 对孵化项目的清理投入了极大的精力，因此项目提议的创建仅仅是万里长征的第一步。除此之外，将现有代码库以 Eclipse 公开许可的方式进行重新许可，对于由 Eclipse 公司成员（Sonatype，Oracle）贡献的代码来说或许是可行的，但对于来自外部的核心功能扩展，则需要更仔细的审查才能允许这部分代码加入。

InfoQ 采访了 Hudson 项目的领导人 Winston Prakash，我们首先询问了为什么孵化项目的清理工作如此重要：

Prakash：在 Hudson 成为 Eclipse Foundation 的顶级技术项目之后，它必须遵守 Eclipse 孵化项目的政策，这有助于降低孵化项目的风险，并且更能吸引其它企业在自己的产品中引入 Hudson。这也支持了 Hudson 一个主要目标，即将其打造为企业级的产品。

InfoQ：要达到政策标准，需要对核心架构做多大程度的改变呢？

Prakash：Eclipse Foundation 法律团队已经看过该产品代码库中的每一行代码（有工具可以实现逐字的代码分析），以确保它遵循以上所有的政策。Hudson 包含的所有第三方类库也经过了法律流程的检验。我们花了一年多时间才达到了政策要求。

InfoQ：3.0 版本的发布是否标志着 Hudson 的一个全新开端，在插件兼容性方面它和 Jenkins 今后又会怎样？

Prakash：我们尽了最大的努力来维护两者的兼容性，在不改变任何现有 API 的前提下提供功能增强。我们将来会继续支持 Jenkins 的插件，并且在我们的发布中进行检验。

我们也将继续鼓励 Hudson 用户为其开发新插件。

InfoQ：Hudson 禁用了构建时自动 JDK 安装，这样做的重要性体现在哪里？

Prakash：这里有个许可方面的问题。根据 Oracle 法律团队的说法，JDK 必须在接受许可条款的前提下才能安装。我们收到报告称，Hudson 和 Jenkins 原先通过屏幕抓取的方式安装 JDK 是非法的。因此我们迅速禁用了 JDK 自动安装功能，直到 JDK 团队能够提供适当的 REST API 为止。

InfoQ：Groovy 插件从框架的关键依赖中移除了，这是什么原因？还能继续使用它吗？

Prakash：从 Hudson 核心中移除 Groovy 的主要原因是归属方面的问题，Eclipse Foundation 不能从 Groovy 团队获得合法的归属权。

通过外部插件依然能够支持 Groovy。这样做的好处在于对脚本的支持进行了抽象，因此将来也许能够用 Scala、Jython、JRuby 等其它 JVM 语言编写脚本。

InfoQ：如何找到 Hudson 3.0 插件，它的站点现在在哪里？

Prakash：特定于 Hudson 的插件，以及来自其它分支且兼容 Hudson 的插件在这里：

• Hudson 3.x 的所有插件 – https://github.com/hudson3-plugins/
• Hudson 2.x 的所有插件 – https://github.com/hudson-plugins/

InfoQ：Hudson 3.x 的未来会怎样？

Prakash：对 Eclipse Foundation 来说最重要的是其稳定性，我们已准备在下个发布（3.1.0）中专注于性能改善。虽然我们也会继续按需添加新特性，不过稳定性和性能才是优先级最高的事务。

查看英文原文： First Hudson Release from Eclipse