Spring Roo 1.0 M1 发布了

Spring Roo 是一个用 Java 开发 Spring 应用的双向（round-tripping）代码生成工具，其最新版提供了 Tomcat 、JMS 和 Selenium 支持。SpringSource 开发团队上周发布了 Roo 1.0 M1 版。

Spring Roo 框架提供了一个带有 tab 命令补全、能感知上下文操作及命令提示特性的命令行 shell。它以标准的目录格式构建 Java 应用程序，管理构建配置文件，帮助开发者创建 domain 对象，集成了流行的持久化技术，并为简单的基于 REST 的 Web 用户界面提供 Web 层自动生成。它还提供了动态查找方法并能自动产生 JUnit 集成测试。

Roo 的项目领导 Ben Alex 最近发表了一篇关于这一新版本的博文，其中带一个例子应用，解释了如何安装框架并用Roo 创建Spring 应用。SpringSource 的创始人 Rod Johnson 也写了一篇关于 Roo 框架背后动机的介绍。InfoQ 就这一新框架及其如何帮助进行Java 应用程序开发等问题采访了Ben Alex。

ROO 是如何自动产生样板（boiler plate）代码，同时又提供灵活性以增加自定义业务逻辑和校验规则的？

对 Roo 产生的所有部件，你都可以用自己选择的编辑器、IDE 或其他工具来编写代码。Roo 位于后台，监视你的项目文件。然后为你的项目构建一个全面的元数据模型。该元数据模型让 Roo 可以识别你所提供的东西以及你想让 Roo 提供的东西。然后它将自动提供这些组件。如果你选择以后自己提供这些组件中的一部分，Roo 也能检测到这一点并透明地删除其自动提供的那部分内容。

ROO 框架使用 Aspect 来描述像 @Configurable 这样的注解。在 Roo 框架中使用 AOP 背后的理由是什么？

至于为什么我们使用 aspect 作为 Java 代码生成的基础，背后有许多动机，我在我的系列博文的第三部分谈到了这一内容。但是实质上我提供了一些不同的备选技术原型，包括 JSR 269 、构建时生成源代码、IDE 插件、开发时产生字节码、运行时产生字节码以及高级反射方法如扩展 Spring Framework AOP、DSL 等等。 我优先要考虑的事情是确保：

• 就算用户停止使用这一工具，他们的项目照样能够进行；这直接就排除了采取任何运行时动作的可能性。
• 在运行时，用户的项目必须不以牺牲性能为代价；这直接排除了大多数反射方法的可能性。
• 开发者要能够使用他们已有的 Java 知识、技巧和经历。于是工具必须支持常规 Java 编程体验、支持开发者的普通编程形式、使他们可以使用自己常用的 IDE，访问熟悉的工具如 debugger 和代码助手。该工具必须能使开发者运用已知、已理解及所期望的东西。这样就排除了任何特定的字节码方法以及大多数运行时方法。
• 该工具必须能自动工作，并且不需要明确调用，也不需要系统集成或建造特定 IDE。它必须绝对支持透明的、即时的 round-tripping。这就排除了 JSR 269 以及构创建于系统等方法，比如类似于 XDoclet 的工具。

其次要考虑： - 用户的项目必须工作于 Java 5 及更高版本上。这就排除了 JSR 269，将其排除的原因还有很多（比如原型时期脆弱的 IDE 支持）。

• 该工具应该容易让最终用户进行扩展。当然，由于我们使用了 AspectJ 技术，这是件非常容易的事。它还不鼓励使用任何特定 IDE 的技术，这可能比 Roo 附加组件需要更复杂的开发和部署过程。
• 该工具对增加附加组件的支持应该是长期的。使用 AspectJ ITD 提供的分离概念可以很容易的实现这一点。
• 该工具应该非常轻量级：下载、学习、运转都应非常迅速。这对一个拥有最少依赖的基于 shell 的方法非常有利。Roo 1.0.0.M1 下载文件小于 3M！

实质上 AspectJ ITDs 增加了一个自动维护的元数据模型，它是我们能找到的唯一解决方案，可以满足所有需求。当然，如果你愿意牺牲一些表达方面的要求的话，自然会有其他方法解决这一问题。

Roo 与其他代码生成工具如 openArchitectureWare（ oAW ）和 Skyway 软件的 Skyway Builder 相比如何呢？

oAW 给应用程序开发提供了一个模型驱动的方法。我相信在许多场景下 MDA 非常有效。不过，Roo 不是一个 MDA 工具。正如我早先在讨论 Roo 背后的重点（在 ROO-1 问题中所表述的）时所提到的，我们的关键要点是提交一个非侵入的且高生产效率的工具，可以利用现有 Java 开发者的知识、技巧及经历。我们相信大多数 Java 开发者更希望用 Java 编写代码，正因为如此，我们开发出了 Roo，并凭借代码优先范式给他们带来高生产效率。这和模型优先范式有很大区别。 题外话，我认为代码优先正是 IDE 流行的原因。人们可以以自己喜欢的方式编写代码，而且比不用 IDE 生产率更高。开发者可以按自己的适应程度逐步的使用 IDE 更多的特性。开发者可以退出 IDE 而他们的项目仍能工作。开始使用 IDE 或停止使用 IDE 都无需“做出重大改变”。一个不需要任何运行时组件（带有相关的性能、兼容性、可移植性及审批问题）的 IDE。这些都是理想特性，并且最终用户会从编程工具中受益。Roo 给快速应用开发带来了所有这些特性。

Skyway Builder 的用户通常都为所期望应用功能创建一个图形表示。然后将其映射到 Java 源代码。我知道 Skyway 正增加一些脚本，支持其基于 Roo 语法的工具。

Skyway 和 oAW 都可以产生标准 Java 源代码并被实现为 Eclipse 插件。相反 Roo 产生的是 AspectJ ITDs。我们评估了源代码生成技巧，感觉把产生的 Java 成员放到单独的 ITD 中更可取。这样避免了把类搞乱，确保了关注点分离并且提供了与未来相关 Roo 附加组件的兼容性。我还要指出的是，Roo 发行的 ZIP 文件小于 3Mb，因此比基于 Eclipse 的工具占用内存更小。加上可以在文本编辑器或非 Eclipse IDE 环境下使用 Roo，没有任何问题。Roo 实际上不需要培训就可以使用——开发者可以在他们希望的任何地方编写代码，Roo 不会做任何干涉。如果使用其他工具，在开始编写代码之前，开发者需要先理解工具要求。

对于有兴趣使用 ROO 框架的开发者，值得推荐的最佳实践及“问题”是什么？

Roo 仍在开发的早期阶段，因此尽管这一技术可能对许多喜欢 Spring 的 Java 开发者来说都有兴趣，但我们还需谨记到目前为止它只公开流通了一个月。我们需要更长的时间来确定功能、修改 bug、接收反馈、编写文档、发布 1.0.0.GA 等等。我们热切期望能收到尽量多的反馈，这将帮助我们交付高质量的 1.0.0.GA 版本（大概是在 2009 年 8 月）。 至于“问题”，在 readme.txt 中有一个已知问题列表。尽管我不认为它们会影响到太多的人，但随着时间推移我们将解决这些问题。还有一个公开的 JIRA 实例罗列了其他一些问题。

在新特性方面，ROO 项目未来的路线图是怎样的？

正如前面所提到的，我们仍把主要精力放在 1.0.0.GA 上。一旦 1.0.0.GA 问世，我们将把 shell 部分从 Roo 中分离出来，放到一个单独的项目中，我们将称之为 Spring Shell。Spring Shell 以后就可以被其他需要 shell 功能的项目所用。另外，我们计划发展一些第四代 Web 应用技术（如 Flex 和 GWT 技术）。我们还将仔细考虑一下未来需要什么样的附加组件功能，哪些新附加组件是社区最想看到的。社区可以通过 Roo社区论坛或问题跟踪系统共享他们对新特性想法、建议和经验。对于那些喜欢以非正式的、直接的方式提供反馈的人，我们也会密切留意#roo Twitter 频道。

查看英文原文： Spring Roo 1.0 M1 Released