blocks|key|1367949|text|主要区别在于Roo是一个纯Java框架，而Grails既利用了Java又利用了Groovy。这两个库都构建在核心Spring库之上，并且都使用了流行的Java开源库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1367950|当Roo宣布时，这个问题被问了回来，Graeme+Rocher+(Grails的负责人)说，这两个框架在Spring中都有一席之地，并且得到了同等的支持。|1367951|如果说有什么不同的话，那就是我认为Grails的未来比Roo更光明。我喜欢用它开发，看不出它不是纯Java有什么坏处。|1367952|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1152926|text|来自SpringSource的Ben+Alex在this+interview中谈到了Roo，他被问及Grails+vs+Roo。除了使用不同的语言(Groovy和Java，正如其他人提到的)之外，主要的区别是Roo主要是一个开发时工具，而Grails更多地参与运行时。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1152927|entityMap|0|LINK|mutability|MUTABLE|url|http://www.infoq.com/interviews/roo-ben-alex^0|O|E|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Ben Alex from SpringSource talks about Roo in <a href="http://www.infoq.com/interviews/roo-ben-alex" rel="nofollow noreferrer">this interview</a> 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.

blocks|key|1152972|text|它们实际上并不那么相似。Roo在编译时实现它的魔力，而Grails在运行时实现它。因此，Roo项目在运行时不会受到任何性能影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1152973|我不明白如何将它们合并，因为Grails构建在Groovy之上，而Roo构建在Java之上。|1152974|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1153034|text|Grails和Roo是非常不同的。第一个主要区别是使用的语言。虽然您可以像编写传统Java代码一样编写Groovy代码，但是仍然需要Groovy依赖项来运行Grails应用程序。为了在Grails中尽可能地高效，您还需要掌握Groovy中当前不是Java一部分的特性，比如闭包。另一个不同之处在于框架生成代码的理念。Grails在运行时生成大量方法，而Roo在开发过程中根据请求生成这些方法。Roo没有幕后接受面向方面编程的魔力，您可以查看Roo生成的所有代码。例如，在Roo中，您必须使用一个命令让它生成动态查找器方法，比如findByBook()，然后在.aj文件中查看生成的代码。在Grails中，findByBook()方法是在运行时创建的，您不能查看生成的代码。如果您愿意，Roo还允许您停止使用框架，同时通过将所有生成的代码合并到普通的.java文件来继续运行应用程序。这样，无论在运行时还是设计时，您都不需要依赖任何Roo库。如果您决定不喜欢Grails，那么就没有办法停止使用该框架，同时继续拥有一个正常运行的应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1153035|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1368262|text|SpringSource的目标是让人们尽可能快速、轻松地构建、运行和管理基于Spring的解决方案，我们同时拥有Grails和Spring+Roo，因为我们非常关心开发人员的生产力，毫无疑问，这两个工具都能极大地提升团队在Spring之上所能实现的目标。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1368263|我们拥有这两种技术，因为Roo和Grails在哲学和实现层面上有很大的不同(正如在其他回复中已经提到的)。每种技术的主要语言(Java或Groovy)和操作模型(开发时或运行时)都遵循这样的理念：“我们如何使用这种语言和操作模型的组合，让价值主张变得令人难以置信地好？”因此，您将看到每种技术采用一种不同的风格来最大化这种组合(Roo的Java%2BDev-time或Grail的Groovy%2BRuntime)以及相应的好处。|1368264|这些差异实际上是非常积极的，因为它们意味着Spring社区可以选择他们喜欢的生产力解决方案的“味道”。虽然围绕语言选择和运行时/开发时操作的这些初始差异是显而易见的，但Grails或Roo的选择也扩展到更微妙的考虑因素，如使用的默认技术、用户交互模型、IDE支持、依赖项、标准、路线图、扩展等。几乎所有这些差异都是为特定语言风格追求最佳解决方案的自然结果。|1368265|我们最好的建议是同时考虑两种解决方案。每种技术都有自己的甜蜜点，但两者之间存在差异，这将使您在给定的上下文中使用一种或另一种技术的整体体验更好。这两个参考指南都详细介绍了each+solution的respective+benefits。当然，请记住，尝试这两种方法的时间投入是最小的。只需10分钟，你就可以用Roo或Grails构建一个项目，所以你可以试一试，看看在你特定的背景和项目需求下，哪一个更适合你。|1368266|entityMap|0|LINK|mutability|MUTABLE|url|http://www.springsource.com/|1|http://www.grails.org/|2|http://www.springsource.org/roo|3|http://grails.org/doc/latest/guide/1.%2520Introduction.html|4|http://static.springsource.org/spring-roo/reference/html/intro.html#intro-why-use-it^0|0|C|0|1K|6|1|1R|A|2|0|0|0|2D|D|3|2R|J|4|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]|$A|13|B|14|1|15]|$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]|$A|1F|B|1G|1|1H]]|C|$]]|$1|J|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]|V|$5|M|N|O|C|$P|W]]|X|$5|M|N|O|C|$P|Y]]]]

<a href="http://www.springsource.com" rel="noreferrer">SpringSource</a>'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 <a href="http://www.grails.org/" rel="noreferrer">Grails</a> and <a href="http://www.springsource.org/roo" rel="noreferrer">Spring Roo</a> 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 <a href="http://static.springsource.org/spring-roo/reference/html/intro.html#intro-why-use-it" rel="noreferrer">respective benefits</a> of <a href="http://grails.org/doc/latest/guide/1.%20Introduction.html" rel="noreferrer">each solution</a>. 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.

blocks|key|1153222|text|我在Grails邮件列表上看到了一些评论，这些评论表明作者认为Roo只是作为Grails的垫脚石而存在！然而，我个人正在考虑从Grails转换到Roo的可能性。我认为动态语言和静态类型语言之间的主要区别-对我来说这是巨大的。我喜欢Grails的许多特性，但我更喜欢它的IDE支持和静态类型语言的编译时检查。其他一些人的想法正好相反，因此马匹参加了课程。也就是说，静态groovy目前正在大力开发中，所以谁知道未来会发生什么呢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1153223|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

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?

Grails vs Roo - why SpringSource is pushing two very similar technologies?

Java

SpringSource (现在的VMWare)有两个非常相似的技术: Grails和Spring Roo。我一直在使用Grails，但我看到SpringSource正在积极地开发该技术的竞争对手，这让我对Grails的未来感到担忧。有谁知道这些技术是如何关联的，它们是将被合并，还是其中一项将被放弃？此外，Grails...

问Grails vs Roo --为什么SpringSource要推动两种非常相似的技术？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Grails vs Roo --为什么SpringSource要推动两种非常相似的技术？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Grails vs Roo --为什么SpringSource要推动两种非常相似的技术？
EN