Grails vs Roo - SpringSourceはなぜ2つの非常によく似た技術を推し進めるのか？

質問

SpringSource（現在はVMWare）には、非常によく似た2つの技術があります。GrailsとSpring Rooです。私はGrailsを使用してきましたが、SpringSourceがその技術の競合となるものに積極的に取り組んでいるのを見ると、Grailsの将来が心配になります。

これらの技術がどのように関連しているのか、統合されるのか、あるいはどちらかが放棄されるのか、どなたかご存知ですか？

また、GrailsとRooの間に重要な技術的な違いはあるのでしょうか？

どのように解決するのですか？

スプリングソース の目標は、人々がSpringベースのソリューションを構築、実行、管理するのをできるだけ迅速かつ容易にすることです。私たちは Grails と Spring Roo というのも、私たちは開発者の生産性に深く関わっており、この2つのツールは間違いなく、チームがSpringの上で達成できることを大幅に後押ししてくれるからです。

RooとGrailsは（他の回答ですでに指摘されているように）哲学的および実装レベルで非常に異なっているため、私たちは両方の技術を持っています。各技術は、主要言語 (Java または Groovy) とオペレーティング モデル (開発時または実行時) に、「この言語とオペレーティング モデルの組み合わせを使って、価値提案を信じられないほど優れたものにするにはどうすればよいか」という哲学をもってアプローチしています。そのため、各テクノロジーでは、その組み合わせ (Roo の Java+Dev-time や Grail の Groovy+Runtime) とそれに見合った利益を最大化する異なるスタイルを採用していることがわかります。

これらの違いは、Springコミュニティが生産性ソリューションのどのフレーバーを好むかを選択できることを意味するので、実際には非常に肯定的なものです。言語の選択とランタイム/デバイスタイム操作に関するこれらの最初の違いはすぐに明らかになりますが、Grails または Roo の選択は、使用されるデフォルトの技術、ユーザー インタラクション モデル、IDE サポート、依存関係、標準、ロードマップ、拡張機能などのより微妙な考慮事項にも及びます。 これらの違いのほぼすべては、特定の言語スタイルのための最善のソリューションを追求することの自然な結果なのです。

私たちの最善のアドバイスは、両方のソリューションを検討することです。それぞれにスイート スポットがありますが、2 つのソリューションには違いがあり、特定のコンテキストにおいて 1 つのテクノロジーまたは他のテクノロジーで全体的なエクスペリエンスを向上させることができます。どちらのリファレンス ガイドでも それぞれの利点 の 各ソリューションの . もちろん、両方を試すのに時間的な投資は最小限であることを忘れないでください。10分もあれば、RooまたはGrailsでプロジェクトを構築することができるので、それらを試してみて、あなたの特定のバックグラウンドとプロジェクトの必要性から、どちらがあなたにとってより自然に感じられるかを見てください。