引言

在过去的一年中，我们对用于保持 Spring 项目系列平稳运行的基础设施和流程进行了一些重大更改。您可能已经看到了一些相关公告，而另一些则可能被您忽略了。我将在下面回顾这些更改。将它们放在一起，可以描绘出一幅更大的图景。

GitHub 项目托管

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

迁移到 Git 和 GitHub 后，项目提交者和 Spring 用户都能从中受益。GitHub 提供了出色的代码浏览、更改历史记录和提交评论用户界面。并且由于 GitHub 上已经托管了大量开源项目，这意味着您正在使用一个易于理解的用户界面，并且您已经知道如何浏览源代码控制、检查最近的更改等等。但 GitHub 的真正强大之处在于它鼓励和支持社区贡献。这一点将在下面的“贡献流程”部分中进一步讨论。

目前，如果您还没有访问过，请查看 GitHub 上的 SpringSource 组织；您会发现我们像往常一样忙碌。

构件管理

位于http://repo.springsource.org的SpringSource 仓库是一个Artifactory 实例，专门用于托管 Spring 项目构件的快照、里程碑、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 仓库常见问题解答应该能够解答您遇到的任何问题。如果没有，请告诉我们！

非常感谢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 自述文件中从源代码构建部分中的完整（但仍然非常简单）说明。将您在那里看到的 100 个单词与几年前我撰写的关于构建 Spring 3的 1500 个单词的博客文章进行比较。我希望您会发现这是一个很大的改进。尝试一下——您甚至可能会喜欢它

Gradle 团队在这个过程中提供了巨大的帮助——Spring 项目经常将 Gradle 推到极限，并在过去几年中用需求挑战团队，而 Gradle 团队一直非常积极响应并乐于助人。许多 Spring 项目如今肯定因为 Gradle 而变得更好，我们希望 Gradle 本身也因为我们抛出的挑战而变得更好一些。祝贺团队获得 1.0 版本！

贡献流程

正如我上面提到的，GitHub 最好的功能之一是拉取请求的概念。如果您还不熟悉，请阅读相关信息，但总而言之，拉取请求就像将补丁和代码审查合并到一个紧密的流程和简单的 UI 中。查看Spring Integration、Spring Framework以及许多其他 Spring 项目的拉取请求历史记录，您会看到许多有趣且有用的示例。此流程已经比将补丁文件附加到 JIRA 好得多；当您将其与 Git 的强大功能和使用 Gradle 进行构建的简便性相结合时，这意味着贡献到 Spring 项目从未如此简单。

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

贡献者的邮件列表

自从我们开始处理拉取请求以来，我们注意到进行了大量的讨论。在一些情况下，这些讨论包含了一些问题，这些问题可能受益于在提交拉取请求之前进行的讨论。此外，这些讨论在某种程度上未被关注，只有那些关注单个拉取请求的人才能看到。毫无疑问，许多人都希望能够关注此类讨论并在相关时参与其中。为框架贡献者提供一个渠道的好处有很多。

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

问题生命周期

由于其众多用户，Spring Framework 项目有特别大量的 issue；可以预见，我们将在今年晚些时候看到第 10,000 个 JIRA issue。面对如此多的涌入 issue，以及 Spring Framework 多样化的功能集，您可以想象保持对所有传入 issue 的掌控有多么困难。在过去的一年中，我们制定了一个分类和积压处理流程，以帮助所有相关人员准确了解每个 issue 的情况。这对我们非常有帮助，我们在issue 的生命周期中对此进行了描述，以便每个人都能理解此流程。

您还会注意到Spring Framework JIRA项目周围的一些较小的更改：一套修订后的组件、简化的问题创建界面以及许多其他调整，旨在使问题报告尽可能有用且轻松。

社区论坛

多年来，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中，参与讨论，还是提交拉取请求，您都在帮助推动对话和整个社区的发展！

脚注

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

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