SpringSource(现在的 VMWare)有两种非常相似的技术:Grails 和 Spring Roo。我一直在使用 Grails，但我看到 SpringSource 正在积极致力于该技术的竞争对手，这让我担心 Grails 的 future 。
有谁知道这些技术是如何关联的，它们会被合并，还是会被放弃？
此外，Grails 和 Roo 之间有什么重要的技术差异吗？
最佳答案
SpringSource 的目标是让人们尽可能快速、轻松地构建、运行和管理基于 Spring 的解决方案。我们有 Grails 和 Spring Roo，因为我们非常关心开发人员的生产力，毫无疑问，这两个工具都极大地促进了团队在 Spring 之上可以实现的目标。
我们拥有这两种技术，因为 Roo 和 Grails 在哲学和实现层面上有很大的不同(正如其他回复中已经指出的那样)。每种技术接近其主要语言(Java 或 Groovy)和操作模型(开发时或运行时)，其理念是“我们如何使用这种语言和操作模型组合使值(value)主张难以置信地好？”。因此，您将看到每种技术都采用不同的风格，以最大化组合(Roo 的 Java+Dev-time 或 Grail 的 Groovy+Runtime)和相应的好处。
这些差异实际上是非常积极的，因为它们意味着 Spring 社区可以选择他们喜欢的生产力解决方案的“风格”。虽然围绕语言选择和运行时/开发时操作的这些初始差异是显而易见的，但选择 Grails 或 Roo 还扩展到更微妙的考虑因素，例如使用的默认技术、用户交互模型、IDE 支持、依赖项、标准、路线图、扩展等。几乎所有这些差异都是为特定语言风格寻求最佳解决方案的自然结果。
我们最好的建议是同时考虑这两种解决方案。每个都有自己的甜蜜点，但两者之间存在差异，这将使您在特定环境中使用一种技术或另一种技术获得更好的整体体验。两个引用指南都详细介绍了 respective benefits 的 each solution 。当然，请记住，在尝试两者时投入的时间很少。在 10 分钟内，您可以在 Roo 或 Grails 中构建一个项目，因此请尝试使用它们，看看根据您的特定背景和项目需求，哪种更适合您。
关于Grails vs Roo - 为什么 SpringSource 正在插入两种非常相似的技术？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2004669/