引言

过去一年里，我们在维护 Spring 项目家族平稳运行所使用的基础设施和流程方面进行了一些重大变更。其中一些变更发生时您可能已经看到了单独的公告，而另一些可能被您忽略了。我将在下面回顾这些变更。它们放在一起呈现了一幅更大的图景。

GitHub 项目托管

单个 Spring 项目迁移到 Git 和 GitHub 已经有一段时间了。您可能还记得去年圣诞节我们发布的公告，宣布 Spring Framework 本身已经完成了迁移。随着 Spring Web Flow 最近的迁移，我们很高兴地宣布，所有主要的 Spring 项目现在都托管在 GitHub 的 SpringSource 组织下。

迁移到 Git 和 GitHub 后，项目提交者和 Spring 用户都将受益。GitHub 提供了优秀的界面，便于浏览代码、查看变更历史和提交注释。鉴于 GitHub 上托管着数量惊人的开源项目，这意味着您将使用一个易于理解的界面，并且已经知道如何浏览源代码控制、检查最新变更等等。但 GitHub 的真正强大之处在于它鼓励和支持社区贡献的方式。这一点将在下面的“贡献流程”部分进一步讨论。

如果您还没有访问过，现在就去看看 GitHub 上的 SpringSource 组织吧；您会发现我们像往常一样忙碌。

构件管理

位于 http://repo.springsource.org 的 SpringSource 仓库是一个 Artifactory 实例，专门用于托管 Spring 项目构件的快照（snapshot）、里程碑（milestone）、RC（Release Candidate）和 GA（General Availability）版本及其传递性依赖。

Spring 构件的 GA 版本将一如既往地继续发布到 Maven Central，但 repo.springsource.org 取代了我们之前在 maven.springframework.org 的基础设施，提供了一个功能更强大的解决方案——带有适当的 UI 和搜索功能，与我们在 build.springsource.org 的 CI 服务器深度集成，以及许多其他有助于项目团队简化发布流程的功能。

对 Spring 用户而言，最终结果是 SpringSource 仓库成为满足您所有 Spring 依赖需求的一站式中心。

如果您的构建脚本中包含 maven.springframework.org 的 URL，它们将无限期地继续工作*，但将来应优先使用 repo.springsource.org，并将前者视为“已弃用”。

更多解释和使用说明可以在 spring-framework GitHub wiki 的下载 Spring 构件页面找到。SpringSource 仓库常见问题解答应该能回答您可能遇到的任何问题。如果不能，请告诉我们！

非常感谢 JFrog 团队——Artifactory 的开发者——与我们合作促成了这件事。在如此多繁忙的项目中切换仓库基础设施本可能导致灾难，但在他们的帮助下一切顺利。同时感谢 Sonatype 团队，他们在 Maven Central 方面的需求上始终给予及时和有益的响应。

基于 Gradle 的构建

将我们的构建从 Ant、Ivy 和 Maven 迁移到 Gradle 是另一个项目逐个进行的迁移过程，这已经持续了一段时间。随着 Gradle 1.0 GA 版本发布的新闻还很新鲜 ](相关新闻)，现在是时候提一下，大多数 Spring 项目现在都使用 Gradle 进行构建**了。

Gradle 拥有许多创新特性，使用起来令人愉悦，例如显着缩短构建时间的增量构建系统、仅显示您需要知道的信息的极简命令行输出，以及简洁的语法，使得使用一个非常小巧且易读的构建脚本来构建像 Spring Framework 这样庞大的代码库成为可能。

对于 Spring 用户来说，用于构建 Spring 项目的系统可能看起来并不重要。确实，就像大多数 Linux 用户不会自己编译内核一样，大多数 Spring 用户也从不从源代码构建 Spring 构件。但像任何好的开源项目一样，有些人会这样做。无论是为了更好地理解 Spring，还是为了进行修改并回馈项目，从源代码构建 Spring 的人数正在增长，这部分归功于 Gradle 使这一过程变得非常简单。Gradle 的一个重要特性是所谓的Gradle Wrapper，它本质上是一个平台原生 shell 脚本，用于下载和安装项目使用的确切 Gradle 版本。这意味着从源代码构建基于 Gradle 的 Spring 项目就像输入以下命令一样简单：

$ git clone https://github.com/SpringSource/spring-framework.git
$ cd spring-framework
$ ./gradlew build

正如您所见，'gradlew' 脚本已签入到项目源代码控制中。因此，随着用于构建项目的 Gradle 版本发生变化，wrapper 会保持最新，并在必要时自动下载新的 Gradle 版本。这意味着永远不会听到“构建坏了”，结果却发现使用了两个不同版本的构建工具。这也意味着 Spring 项目可以立即跟上 Gradle 的最新变化，而不会冒着破坏其他提交者和贡献者构建的风险。

请查看 Spring Framework readme 中关于从源代码构建部分的完整（但仍然非常简单）说明。将其与我几年前写的关于构建 Spring 3 的 1,500 字博客文章进行比较。我希望您会发现这有了很大的改进。试试看吧——您甚至可能会喜欢它。

Gradle 团队在此过程中给予了巨大帮助——在过去的几年里，Spring 项目经常将 Gradle 推向极限，并向团队提出了各种需求，而 Gradle 团队始终响应及时且乐于助人。许多 Spring 项目今天因 Gradle 而变得更好，我们也希望 Gradle 本身能因我们提出的挑战而至少有所改进。恭喜团队发布 1.0 版本！

贡献流程

正如我上面提到的，GitHub 最好的事情之一就是拉取请求（pull requests）的概念。如果您还不熟悉，请阅读相关资料，简单来说，拉取请求就像是将补丁和代码审查集成到一个紧密流程和简单界面中。看看 Spring Integration、Spring Framework 以及许多其他 Spring 项目的拉取请求历史记录，您会看到许多有趣且有用的例子。这个过程已经比将补丁文件附加到 JIRA 好得多；当您将其与 Git 的强大功能以及使用 Gradle 构建的便利性结合起来时，意味着向 Spring 项目贡献代码从未如此简单。

自 Spring Framework 在 2011 年底迁移到 GitHub，到本文撰写的 2012 年 6 月，该项目已收到超过 100 个拉取请求。并非每个拉取请求都能被接受。结果取决于审查流程，但尽管如此，许多贡献已经进入项目，有时是在经过大量讨论和完善之后。我们根据这段时间学到的经验，整理了一份贡献者指南文档；如果您想回馈框架，请阅读一下。这是让您的议题排在前面的一种好方法。我们自然会对那些花时间提交高质量贡献的用户给予一些优先权。感谢所有已经这样做的贡献者，也提前感谢未来的贡献者！

贡献者邮件列表

自从我们开始处理拉取请求以来，我们注意到正在进行着非常好的讨论。在某些情况下，这些讨论包含的问题如果在提交拉取请求之前进行讨论可能会更有益。此外，这些讨论在一定程度上仍然不太引人注目，并且只有关注单个拉取请求的人才能看到。毫无疑问，许多人希望能够关注此类讨论并在相关时参与进来。为框架贡献者提供一个交流渠道的好处有很多。

我们很高兴通过这篇博客文章宣布在 Google Groups 上托管的新邮件列表 spring-framework-contrib。该列表专门面向希望为 Spring Framework 项目贡献代码的开发者。这是一个您可以直接与提交者和其他贡献者讨论您的想法的地方——无论是在编写代码之前还是之中。我们鼓励任何考虑提交拉取请求的人加入该群组并在那里与我们讨论您的想法。

议题生命周期

由于拥有众多用户，Spring Framework 项目的议题数量特别多；可以预见的是，今年晚些时候我们将看到第 10,000 个 JIRA 议题。随着如此多的议题涌入，并且覆盖 Spring Framework 多样化的功能集，您可以想象掌握所有传入议题可能会有多么困难。在过去的一年里，我们制定了一套分流和积压流程，帮助所有相关人员准确了解每个议题的进展。这对我们非常有帮助，我们已将其在议题的生命周期中进行描述，以便每个人都能理解这个过程。

您还会注意到 Spring Framework JIRA 项目周围的一些小改动：一套修订的组件、简化的议题创建屏幕以及许多其他旨在使议题报告尽可能有用和轻松的调整。

社区论坛

多年来，Spring 论坛一直是并将继续是 Spring 相关问答的好地方。截至本文撰写时，已有超过 10 万名成员发布了超过 10 万个主题（总计近 40 万条帖子！）。这还不包括每天数千名未登录就访问网站的访客。毫无疑问，这将长期以来一直是一个宝贵的资源。

还有另一个问答资源，我们想确保 Spring 社区的每个人都知道。您可能知道，过去几年，Stack Overflow 已成为一个极其流行的编程问答资源。Spring 相关的问答也不例外。如果您访问 http://stackoverflow.com/tags 并输入“spring”，您会看到已经有很多 Spring 相关的标签，其中spring 和 spring-mvc 是最受欢迎的。我以及 Spring 团队的其他成员经常对 Stack Overflow 上的讨论质量印象深刻，我们非常高兴看到并感谢所有提供出色答案的人。

像 Stack Overflow 这样的基于标签的系统，本质上比 Spring 论坛提供的严格面向项目的分类更难界定，但我们建议，如果您有 Spring Framework 特有的问题，请酌情使用 'spring' 或 'spring-mvc' 标签。如果您有与 Spring Integration 相关的问题，请使用 spring-integration 标签，依此类推。这其实很直观。

总结

希望您同意，上述变更使我们所有人比以往任何时候都更容易合作，这是任何开源项目成功的关键因素。我们鼓励您花时间查阅本文中提到的资源，并尝试和利用可用的内容。请记住，贡献有多种形式——无论是在 JIRA 中创建明确的议题，参与讨论，还是提交拉取请求，您都在帮助推动对话和整个社区的发展！

脚注

* 旧的 maven.springframework.org URL 将继续有效，因为 maven.springframework.org 的 DNS 记录现在指向 repo.springsource.org，并且 /snapshot、/milestone 和 /release 路径现在映射到 repo.springsource.org 上同名且内容相同的“虚拟仓库”。

** 各个 Spring 项目团队可以自由选择最适合他们的构建工具。这意味着虽然许多项目已迁移到 Gradle，但可以预见其他项目将继续使用 Maven。