Grails 与 Roo - 为什么 SpringSource 正在推动两种非常相似的技术？
SpringSource（现在的 VMWare）有两种非常相似的技术：Grails 和 Spring Roo。我一直在使用 Grails，但我看到 SpringSource 正在积极开发一些与该技术竞争的东西，这让我对 Grails 的未来感到担忧。
有谁知道这些技术是如何关联的，它们是否会被合并，或者其中一项会被放弃？
此外，Grails 和 Roo 之间有什么重要的技术差异吗？
SpringSource (now VMWare) has two very similar technologies: Grails and Spring Roo. I have been using Grails, but I see that SpringSource is actively working on something that is a competitor for that technology and that makes me worried about the future of Grails.
Does anyone know how these technologies relate, are they going to be merged, or one of them will be abandoned?
Besides, are there any important technical differences betweent Grails and Roo?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
SpringSource 的目标是让人们尽可能快速、轻松地构建、运行和管理基于 Spring解决方案。我们有 Grails 和 Spring Roo 因为我们非常关心开发人员的生产力，毫无疑问，这两种工具都极大地提高了团队在 Spring 之上实现的目标。
我们拥有这两种技术，因为 Roo 和 Grails 在哲学和实现层面上非常不同（正如其他回复中已经指出的）。每种技术都以“我们如何使用这种语言和操作模型组合使价值主张难以置信地好？”的理念来处理其主要语言（Java 或 Groovy）和操作模型（开发时或运行时）。因此，您将看到每种技术采用不同的风格，最大限度地发挥这种组合（Roo 的 Java+Dev-time 或 Grail 的 Groovy+Runtime）以及相应的优势。
这些差异实际上是非常积极的，因为它们意味着 Spring 社区可以选择他们喜欢的生产力解决方案“风格”。虽然围绕语言选择和运行时/开发时操作的这些最初差异是显而易见的，但 Grails 或 Roo 的选择还扩展到更微妙的考虑因素，例如使用的默认技术、用户交互模型、IDE 支持、依赖项、标准、路线图、几乎所有这些差异都是为特定语言风格追求最佳解决方案的自然结果。
我们最好的建议是考虑这两种解决方案。每种技术都有其最佳优点，但两者之间存在差异，这将使您在给定环境中使用一种技术或另一种技术时获得更好的整体体验。两个参考指南都详细介绍了各自的优势每个解决方案的 a>。当然，请记住，尝试这两种方法所花费的时间是很少的。 10 分钟内，您就可以在 Roo 或 Grails 中构建一个项目，因此请尝试一下，根据您的特定背景和项目需求，看看哪种方式对您来说更自然。
SpringSource's goal is to make it as fast and easy as possible for people to build, run and manage Spring-based solutions. We have both Grails and Spring Roo because we deeply care about developer productivity and unquestionably both of these tools deliver a serious boost to what teams can achieve on top of Spring.
We have both technologies because Roo and Grails are very different at philosophical and implementation levels (as already noted in the other replies). Each technology approaches its primary language (Java or Groovy) and operating model (dev-time or runtime) with the philosophy of "how do we make the value proposition unbelievably good using this language and operating model combination?". As such you'll see each technology adopting a different style that maximises that combination (Roo's Java+Dev-time or Grail's Groovy+Runtime) and the commensurate benefits.
These differences are actually very positive, because they mean the Spring community can chose which "flavour" of productivity solution they prefer. While these initial differences around language choice and runtime/dev-time operation are immediately apparent, the choice of Grails or Roo also extends to more subtle considerations such as the default technologies used, user interaction model, IDE support, dependencies, standards, roadmap, extensions etc. Nearly all of these differences are a natural consequence of pursuing a best-of-breed solution for a particular language style.
Our best advice is to consider both solutions. Each have their sweet spots, but there are differences between the two which will make your overall experience better with one technology or the other in a given context. Both reference guides detail the respective benefits of each solution. Of course, remember the time investment is minimal in trying both out. In 10 minutes you can build a project in Roo or Grails, so give them a try and see what feels more natural for you given your specific background and project needs.
主要区别在于 Roo 是纯 Java 框架，而 Grails 则利用 Groovy 和 Java。两者都基于核心 Spring 库构建，并利用流行的 Java 开源库。
当 Roo 发布时有人提出这个问题，Graeme Rocher（Grails 负责人）表示这两个框架在 Spring 中都占有一席之地并且受到同等支持。
如果有的话，我认为 Grails 的未来比 Roo 更光明。我喜欢用它进行开发，并且不认为它不是纯 Java 有任何缺点。
The main difference is that Roo is a pure Java framework whereas Grails leverages Groovy as well as Java. Both are built on the core Spring libraries and make use of popular Java open source libraries.
This question was asked back when Roo was announced and Graeme Rocher (Grails lead) says that both frameworks have a place within Spring and are supported equally.
If anything, I think Grails has a brighter future than Roo. I love developing with it and don't see any downsides to it not being pure Java.
Grails 和 Roo 有很大不同。第一个主要区别是使用的语言。虽然您可以像传统 Java 代码一样编写 Groovy 代码，但您仍然需要 Groovy 依赖项来运行 Grails 应用程序。为了尽可能提高 Grails 的工作效率，您还需要掌握 Groovy 中目前不属于 Java 的功能，例如闭包。另一个区别是框架生成代码的理念。 Grails 在运行时生成许多方法，而 Roo 在开发过程中根据请求生成它们。 Roo 对于面向方面编程的使用没有幕后魔法接受，您可以查看 Roo 生成的所有代码。例如，在 Roo 中，您必须使用命令让它生成动态查找方法（例如 findByBook()），然后在 .aj 文件中查看生成的代码。在 Grails 中，findByBook() 方法是在运行时创建的，您无法查看生成的代码。 Roo 还允许您停止使用该框架（如果您选择），同时通过将所有生成的代码合并到正常的 .java 文件中来继续运行应用程序。这样，您在运行时或设计时就不再依赖任何 Roo 库。如果您决定不喜欢 Grails，则无法在继续拥有正常运行的应用程序的同时停止使用该框架。
Grails and Roo are very different. The first major difference is the language used. While you can write Groovy code like traditional Java code you still need the Groovy dependencies to run Grails applications. To be as productive as possible in Grails you also need to have a grasp of features in Groovy that are not currently part of Java such as Closures. Another difference is the philosophy the frameworks take to generating code. Grails generates a lot of methods at runtime while Roo generates them on request during the development process. Roo has no behind the scenes magic accept for the usage of aspect oriented programming, and you can view all the code that Roo generates. For example in Roo you must use a command to have it generate dynamic finder methods such as findByBook() and then view the generated code in the .aj files. In Grails the findByBook() method is created at runtime, and you can’t view the generated code. Roo also allows you to stop using the framework if you chose while continuing to have a running application by merging all the generated code into normal .java files. You then have no dependencies on any Roo libraries at either runtime or design time. If you decide you don’t like Grails there’s no way to stop using the framework while continuing to have a functioning application.
IMO 两者不太相似。尽管有相似之处，但以下是显着差异：
Grails 是基于 Groovy 的
Roo 与 Grails 的命令行系统非常相似（例如
create-app、create-domain-class，在 Grails 中找到的test-app类型命令）。如果看到 Grails 框架的这一部分和 Roo 之间存在某种“异花授粉”，我不会感到惊讶。IMO the two are not very similar. Even though there are similarities the following are significant differences:
Grails is based on Groovy
Roo is very similar to Grails' command line system (e.g. the
create-app,create-domain-class,test-apptype commands found in Grails). I would not be surprised to see some "cross-pollination" between this part of the Grails framework and Roo.来自 SpringSource 的 Ben Alex 在本次采访中谈论了 Roo，并被问到了有关 Grails 的问题对阵鲁。除了使用不同的语言（Groovy 与 Java，如其他人提到的）之外，主要区别在于 Roo 主要是一个开发时工具，而 Grails 更多地涉及运行时。
Ben Alex from SpringSource talks about Roo in this interview and he is asked about Grails vs Roo. The main difference besides using different languages (Groovy vs Java as others mentioned) is that Roo is mainly a development time tool and Grails is more involved in runtime.
他们其实没那么相似。 Roo 在编译时发挥作用，而 Grails 则在运行时发挥作用。因此，Roo 项目在运行时不会受到任何性能影响。
我看不出它们如何合并，因为 Grails 是基于 Groovy 和 Roo on Java 构建的。
They're actually not that similar. Roo does it's magic at compile time, where Grails is does it runtime. Because of that Roo projects does not take any performance hits at runtime.
I can't see how they could be merged as Grails is built upon Groovy and Roo on Java.
我在 Grails 邮件列表上看到了一些评论，这些评论表明作者认为 Roo 的存在只是作为 Grails 的垫脚石！不过，我个人正在考虑从 Grails 切换到 Roo。我认为主要区别在于动态和静态类型语言之间 - 对我来说这是巨大的。我喜欢 Grails 的许多功能，但我更喜欢静态类型语言的 IDE 支持和编译时检查。其他一些人的感觉恰恰相反，因此选择了马。也就是说，staticgroovy 目前正在大力开发中，所以谁知道未来会怎样。
I saw some comments on the Grails mailing lists which indicated that the authors believed that Roo exists only as a stepping-stone to Grails! However I am personally considering a possible switch from Grails to Roo. I think the main difference is between dynamic and statically typed languages - to me this is huge. I love many features of Grails but I prefer the IDE support and compile-time checking of a statically typed language. Some others feel exactly the opposite, hence horses for courses. That said, static groovy is currently under heavy development so who knows what the future holds.
我们有一个要求，即我们在生产中有一个应用程序，并且是在 Spring MVC 中开发的，但开发新功能的速度很慢。我们必须探索 Grails 和 Roo 等替代框架。我个人花了近一个月的时间来探索哪一个更好。
如果您想查看分析的详细信息，请访问@ http://krishnasblog。 com/2012/05/08/roo-vs-grails/
我们在这两个项目中探索了以下功能，下面是我们的发现。最终判决我们不确定是否会使用其中任何一个，我们仍在探索
We had a requirement where we had an application in production and was developed in Spring MVC and the velocity of developing new features were slow. We had to explore alternate frameworks like Grails and Roo. I personally spent close to a month exploring which one was better.
If you want to see the details of the analysis visit @ http://krishnasblog.com/2012/05/08/roo-vs-grails/
We explored following features in both these and below is our findings. The final verdict we are not sure we will use either one, we are still exploring