Spring Roo 1.0 M1发布了

作者 Srini Penchikala 译者 宋玮 发布于 2009年6月8日

领域

语言 & 开发

主题

Java ,

Web框架

标签

代码生成

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

译者 宋玮 有多年软件开发经验，长期担任技术管理和项目管理工作，一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。

• 更早的 >