介绍

在过去的一年里，我们在维护 Spring 系列项目顺利运行所需的基础设施和流程方面进行了一系列重大更改。您可能已经看到了一些相关的单独公告，而另一些可能已经悄悄地发生了。我将在下面回顾这些更改。将它们放在一起，可以看到一个更大的图景。

GitHub 项目托管

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

迁移到 Git 和 GitHub 对项目贡献者和 Spring 用户都有好处。GitHub 提供了出色的 UI，用于代码浏览、更改历史记录和提交注释。而且，GitHub 上已经托管了大量开源项目，这意味着您使用的是一个大家熟悉的 UI，并且已经知道如何浏览源代码控制、检查最近的更改等等。但 GitHub 的真正强大之处在于它鼓励和支持社区贡献的方式。这一点将在下面的“贡献流程”部分进一步讨论。

目前，如果您还没有看过 GitHub 上的 SpringSource 组织，不妨去看看；您会发现我们一如既往地忙碌。

构件管理

位于 http://repo.springsource.org 的 SpringSource 仓库是一个 Artifactory 实例，专门用于托管 Spring 项目构件的 snapshot、milestone、RC 和 GA 版本，以及它们的传递性依赖。

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

对 Spring 用户来说，SpringSource 仓库是满足您所有 Spring 依赖需求的一站式服务。

如果您在构建脚本中有 maven.springframework.org 的 URL，它们将继续正常工作*，但未来应将这些 URL 视为“已弃用”，并优先使用 repo.springsource.org。

有关进一步的解释和使用说明，请参阅 spring-framework GitHub wiki 上的 下载 Spring 构件页面。 SpringSource 仓库 FAQ 应该能回答您可能遇到的任何问题。如果不能，请告诉我们！

非常感谢 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 版本发生变化，包装器会保持最新，并在必要时自动下载新版本的 Gradle。这意味着您永远不会听到“构建失败”的消息，然后发现正在使用两个不同版本的构建工具。而且这意味着 Spring 项目可以立即跟上 Gradle 的最新变化，而不会冒着破坏其他提交者和贡献者构建的风险。

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

在整个过程中，Gradle 团队提供了巨大的帮助——在过去的几年里，Spring 项目不断挑战 Gradle 的极限并向团队提出各种需求，而 Gradle 团队始终响应迅速且乐于助人。许多 Spring 项目如今无疑受益于 Gradle，我们也希望 Gradle 本身至少能因我们给它带来的挑战而有所进步。祝贺团队发布 1.0 版本！

贡献流程

如上所述，GitHub 最好的特性之一就是 拉取请求 (pull requests) 的概念。如果您还不熟悉，请务必阅读一下，但可以肯定地说，拉取请求就像补丁和代码审查一样，被整合到一个紧密的流程和一个简单的 UI 中。查看 Spring Integration、Spring Framework 以及其他许多 Spring 项目的拉取请求历史记录，您会看到大量有趣且有用的示例。这个过程已经比将补丁文件附加到 JIRA 要好得多；当您将其与 Git 的强大功能和 Gradle 的易用性结合起来时，这意味着为 Spring 项目做出贡献从未如此简单。

自 Spring Framework 于 2011 年底迁移到 GitHub，截至本文撰写之时（2012 年 6 月），该项目已收到 100 多个拉取请求。并非所有拉取请求都能被合并。结果取决于审查过程，但尽管如此，许多贡献仍然被采纳，有时是在经过大量讨论和完善之后。我们根据在此期间学到的知识，整理了一份 贡献者指南文档；如果您有任何想要贡献给框架的内容，请阅读一下。这是让您的 issue 获得优先处理的好方法。我们自然会优先考虑那些花时间准备高质量贡献的用户。感谢所有已经这样做过的人，也感谢未来的贡献者！

贡献者邮件列表

自我们开始处理拉取请求以来，我们注意到正在进行伟大的讨论。在某些情况下，它们包含一些问题，这些问题如果在提交拉取请求之前进行讨论可能会更有益。此外，这些讨论仍然有些隐蔽，只有关注单个拉取请求的人才能看到。毫无疑问，你们中的许多人希望能够关注这些讨论并在相关时参与其中。为框架贡献者提供一个交流渠道有很多好处。

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

Issue 生命周期

由于拥有众多用户，Spring Framework 项目的问题数量尤其庞大；预计今年晚些时候我们将看到第 10,000 个 JIRA issue。随着如此多的 issue 涌入，以及 Spring Framework 庞大的功能集，您可以想象要跟上所有新进 issue 的难度。在过去的一年里，我们设计了一个分类和积压流程，帮助所有相关人员准确了解每个 issue 的进展情况。这对我们非常有帮助，我们已将其描述在 issue 的生命周期中，以便每个人都能理解这个流程。

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

社区论坛

多年来，Spring 论坛一直是 Spring 相关问答的绝佳场所，并且至今仍然是。在本文撰写之时，已有超过 100,000 个主题（总计近 400,000 篇帖子！）来自超过 100,000 名成员。这还没有算上每天成千上万的访客，他们不登录也浏览该网站。毫无疑问，这将继续是一个宝贵的资源。

我们希望让 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 中定义明确的 issue、参与讨论，还是提交拉取请求，您都在帮助推动对话和整个社区的进步！

脚注

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

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