问题描述
SpringSource(现在的 VMWare)有两个非常相似的技术:Grails 和 Spring Roo.我一直在使用 Grails，但我看到 SpringSource 正在积极致力于该技术的竞争对手，这让我担心 Grails 的未来.
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?
此外，Grails 和 Roo 之间有什么重要的技术差异吗?
Besides, are there any important technical differences betweent Grails and Roo?
推荐答案
SpringSource 的目标是实现尽可能快速和轻松地构建、运行和管理基于 Spring 的解决方案.我们有 Grails 和 Spring Roo，因为我们非常关心开发人员的生产力，毫无疑问，这两种工具都极大地促进了团队在 Spring 之上的成就.
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.
我们拥有这两种技术，因为 Roo 和 Grails 在哲学和实现层面上有很大不同(如其他回复中所述).每种技术接近其主要语言(Java 或 Groovy)和操作模型(开发时或运行时)，其理念是我们如何使用这种语言和操作模型组合使价值主张难以置信地好?".因此，您将看到每种技术都采用不同的风格，以最大化组合(Roo 的 Java+Dev-time 或 Grail 的 Groovy+Runtime)和相应的好处.
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.
这些差异实际上是非常积极的，因为它们意味着 Spring 社区可以选择他们喜欢的生产力解决方案的风格".虽然围绕语言选择和运行时/开发时操作的这些初始差异是显而易见的，但 Grails 或 Roo 的选择还扩展到更微妙的考虑因素，例如使用的默认技术、用户交互模型、IDE 支持、依赖项、标准、路线图、扩展等.几乎所有这些差异都是为特定语言风格寻求同类最佳解决方案的自然结果.
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.
我们最好的建议是同时考虑这两种解决方案.每个都有自己的甜蜜点，但两者之间存在差异，这将使您在特定环境中使用一种技术或另一种技术获得更好的整体体验.两个参考指南都详细介绍了各自的好处每个解决方案中的一个>.当然，请记住，尝试两者所花费的时间是最少的.在 10 分钟内，您可以在 Roo 或 Grails 中构建一个项目，因此请尝试使用它们，看看根据您的特定背景和项目需求，哪种更适合您.
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.
这篇关于Grails 与 Roo - 为什么 SpringSource 正在推动两种非常相似的技术?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！