几周前，Spring Framework项目在其SourceForge主页上的下载量突破了100万次。真实的总数可能要高得多，因为这个数字不包括每日构建或Spring可以下载的其他站点。当然，Spring也被包含在大量且不断增长的其他产品的发行版中。还有Spring.NET……

最重要的是，Spring持续发展势头：下载量增长非常迅速。Spring下载量最大的版本是最新生产版本1.2.8，下载量已达175,000次……

关于我最近关于 Spring 和 Maven 的声明，已经有了相当多的讨论。这些讨论都非常好且有价值，但我确实想澄清我提出的一些观点。

首先，我们致力于支持使用 Maven 作为首选构建系统的 Spring 用户。这意味着我们将帮助确保从 Spring 2.0 RC4 开始的每个 Spring 版本在 Maven 仓库中都有准确的 POM。这就是世界上最受欢迎的 JIRA 问题的全部意义。仅此而已。

Spring内部构建系统的话题是……

Spring Framework 2.0 RC4 已发布。这是 Spring 2.0 最终版本之前的最后一个候选发布版，您可以从发布公告本身以及JIRA 问题列表了解有关此版本的更多信息，以获取此版本中更改的完整列表。

可能最重要的一点是，此版本为 2.0 DTD 和 Schema (XSD) 引入了带版本的文件/位置名称。这是必要的，因为 2.0 的 XML Bean 定义格式得到了显著增强，但 1.2.x 用户仍然需要能够引用 1.2.8 DTD。以下是使用 2.0“beans”schema 的示例（2.0 还附带了许多其他新 schema，代表各种特殊命名空间…

你猜是什么？如果你猜是 Spring 的Maven bundle/build，你就赢了。12 月来Spring Experience找我，我们将分享一杯冰镇饮料作为你的奖品。

我的过失

在我过去的职业生涯中，我做了很多配置管理和构建系统方面的工作。当我来到 Interface21 后，我立即自愿尽我所能帮助构建基础设施。接下来，我发现所有与 Maven 相关的票证，无论是 Spring 还是 Spring Web Flow，都被分配给了我。然后，由于我对 JIRA 的漫不经心，我让这个问题发酵了。在过去的几个月里，关于 Spring 和 Maven 的事情确实一直在向前推进；我本应该在 JIRA 中发布但却没有发布的事情。这导致最近几天在主要 JIRA 问题中出现了一些合理的抱怨。因此，为了让大家了解最新情况，以下是当前的状况。

状态

对于过去几个月对 Spring 2.0 和 Maven 感到绝望的人，你们不会再绝望太久了。Spring 社区已决定逐步将所有 Spring 项目转换为 Maven。您可能知道Acegi 长期以来一直在使用 Maven。最近，Spring-WS 项目也进行了转换。我个人已经原型化了Spring Web Flow的转换，并且普遍认为 Spring 也将进行转换。

话虽如此，现在还不是庆祝的时候。转换最后两个项目（Spring 和 Spring Web Flow）并非易事（如果您不相信我，只需看看《使用 Maven 构建更好的项目》）。因此，这种转换并不是我们真的想在接近主要 2.0 和 1.0 版本发布时做的事情。我能告诉您的是，转换是一个计划在发布之后实现的目标。

那计划是什么？

其实很简单。在接下来的几周里，我将为 Spring 和 Spring Web Flow 手动构建带有依赖列表的 POM。目前，计划是将这些 POM 与 Spring 和 Spring Web Flow 的最终版本一起发布。发布之后，在 Arjen 的帮助下，我将协助 Juergen 和 Keith 将他们的源代码树转换为 Maven 构建，并让这些构建在 Continuum 中运行。

那么，我作为用户，在此期间能做些什么呢？

首先是要有耐心。我们在这个问题上沉默了这么久是我的错，希望这篇文章能为我们的思考过程提供一些透明度。其次，我很乐意提供测试帮助。我的计划是在工作时将试用 POM 签入 CVS 和 SVN，并在JIRA 问题上宣布已进行更改。正如你所猜，手动创建 POM 容易出错（这是推动 Maven 构建的驱动因素之一），所以我很乐意得到一些测试它们的帮助。在JIRA 中的评论，发帖到论坛，以及发帖到开发者邮件列表都是很好的反馈途径。

还有其他你想知道的吗？

再次，我希望这能缓解社区中的一些沮丧情绪，并让您了解我们未来的方向。当然，欢迎对当前计划提出任何意见（这里的评论将是一个很好的地方），但我也想知道您是否有任何其他问题或让您感到沮丧的问题。如果您在下面留下问题或直接给我发送电子邮件，我将尽力给您一个满意的答复，并将其发布到博客上或通过电子邮件直接回复给您。

它始于一件小事。仅仅是我的一种直觉，认为 Spring 和 OSGi 应该很好地协同工作。这个想法是，通过使 Spring 应用程序能够部署在 OSGi 运行时中，我们可以为 Spring 应用程序带来更好的模块化、版本控制、运行时部署和更新功能。这是一个我从未真正宣传过的项目；我只是开始实验，与一些人交谈，并编写了一些早期的原型代码。

事实证明，很多人似乎对Spring和OSGi感兴趣。我们正在与来自BEA、Oracle、IBM、Eclipse、OSGi联盟以及其他几家的代表进行合作，以建立一个关于Spring对OSGi支持应该是什么样子，以及如何使在OSGi运行时上构建企业应用程序变得容易的共享模型。最新版本的规范附在Spring JIRA问题1802中。这是规范文本的直接链接……

正如大家所知，Spring 2.0 的一大改进是增加了 AspectJ 切入点语言以及与 AspectJ 的更好集成。虽然我认为从长远来看，这会带来巨大的好处，但也导致了一些问题。我们发现 Spring AOP 始终具有某些 AspectJ 从未具有的行为。

出现的一个大问题是Before advice的行为。如果你在Spring 1.x中使用过Spring AOP，你可能知道Spring允许你在参数传递给目标之前更改其值……

Spring - 将长期存在 我每天都会拜访许多客户，并与更多客户交谈。这包括现有的 Interface21 客户以及对我们在欧洲的产品和服务感兴趣的公司。我注意到我正在进行的对话中有一个反复出现的主题：Spring 在这里，而且它将长期存在。

在过去的一年里，我见证了高层决策，这些决策已将 Spring 标准化到领先的企业 Java 开发公司的整个结构中。就在两周前，我问我的一位客户——欧洲最大公司之一的 Java 部门经理……

最近我似乎一直专注于创建 Spring XML 命名空间。在 XSD 和 Spring 两方面，为了找到创建解析器的良好模式，经历了大量的尝试和错误。我遇到的最大困惑之一是 AbstractBeanDefinitionParser 层次结构。目前它的文档不是特别好（但有一个 JIRA 问题，所以会在 GA 之前修复），所以我将为您介绍您的选择、它们的作用以及如何使用它们。

AbstractBeanDefinitionParser 的选择

Spring 提供了三种主要的 BeanDefinitionParser 来帮助您解析 XML 命名空间。

• AbstractBeanDefinitionParser
  • AbstractSingleBeanDefinitionParser
    • AbstractSimpleBeanDefinitionParser

我将从最具体的地方开始，逐步深入到最一般的地方，以展示在需要时如何获得更大的能力。如果你想跳过示例并查看摘要，请点击这里……

大家好！

这是我上个月加入 Interface21 以来发布的第一篇文章。我之前的博客现在已正式弃用，我将不再更新它。

那么我第一篇文章的主题是什么（除了自我介绍）？  验证逻辑。  这不会是关于如何在 Spring 框架中执行验证的演练，而是会讨论我一个特别恼人的问题：)

特别是，我想讨论验证逻辑中应该包含哪些内容。  这似乎是一个无需思考的答案；“验证指定数据的逻辑”。  好的，这确实是一个无需思考的答案，但请继续阅读 :)。如您所知，Spring 框架通过 Errors 和 Validator 接口为您的验证提供了一个很好的抽象层。  特别是，Validator 是您将业务特定的验证规则应用于填充的领域对象的地方。  Spring 出色的绑定支持负责更新您的领域模型…