GrailsとRoo-SpringSourceが2つの非常によく似たテクノロジーを推進しているのはなぜですか？
SpringSource（現在のVMWare）には、GrailsとSpring Rooという2つの非常に類似したテクノロジーがあります。私はGrailsを使用してきましたが、SpringSourceは積極的にその技術の競争相手であることに取り組んでおり、Grailsの将来について心配しています。
これらの技術がどのように関連しているかを知っている人はいますか？
さらに、GrailsとRooの間に重要な技術的な違いはありますか？
SpringSource の目標は、Springベースのソリューションの構築、実行、管理をできる限り迅速かつ簡単にすることです。 Grails と Spring Roo の両方があります。開発者の生産性に深く関心があり、これらのツールはどちらも、チームがSpringで達成できることを大きく後押しするからです。
RooとGrailsは哲学レベルと実装レベルで非常に異なるため、両方のテクノロジーがあります（他の回答で既に述べたように）。各テクノロジは、「この言語とオペレーティングモデルの組み合わせを使用して価値提案を信じられないほど優れたものにする方法」という哲学で、主要言語（JavaまたはGroovy）とオペレーティングモデル（開発時または実行時）にアプローチします。そのため、各テクノロジーは、その組み合わせ（RooのJava + Dev-timeまたはGrailのGroovy + Runtime）とそれに見合ったメリットを最大化する異なるスタイルを採用しています。
これらの違いは、Springコミュニティが生産性ソリューションの「フレーバー」を選択できることを意味するため、実際には非常にポジティブです。言語の選択とランタイム/開発時の操作に関するこれらの初期の違いはすぐに明らかになりますが、GrailsまたはRooの選択は、使用されるデフォルトのテクノロジー、ユーザーインタラクションモデル、IDE =サポート、依存関係、標準、ロードマップ、拡張など。これらの違いのほとんどすべては、特定の言語スタイルに最適なソリューションを追求することの当然の結果です。
最善のアドバイスは、両方のソリューションを検討することです。それぞれにスイートスポットがありますが、2つのテクノロジーには違いがあり、特定のコンテキストで1つのテクノロジーまたは他のテクノロジーの全体的なエクスペリエンスが向上します。両方のリファレンスガイドでは、- 各メリット各ソリューション について詳しく説明しています。もちろん、両方を試す際の時間投資は最小限であることを忘れないでください。 10分でRooまたはGrailsでプロジェクトを構築できるので、特定の背景とプロジェクトのニーズを考慮して、あなたにとってより自然に感じるものを試してみてください。
主な違いは、Rooは純粋なJavaフレームワークであるのに対して、GrailsはJavaと同様にGroovyを活用していることです。どちらもコアスプリングライブラリ上に構築され、一般的なJavaオープンソースライブラリを使用します。
Rooが発表されたときにこの質問が返され、Graeme Rocher（Grailsが率いる）は、両方のフレームワークがSpring内に存在し、等しくサポートされていると言います。
どちらかといえば、GrailsはRooよりも明るい未来を持っていると思います。私はそれを使って開発するのが大好きで、純粋なJavaではないというマイナス面はありません。
GrailsとRooは非常に異なります。最初の大きな違いは、使用される言語です。従来のJavaコードのようなGroovyコードを書くことができますが、Grailsアプリケーションを実行するにはGroovyの依存関係が必要です。Grailsで可能な限り生産性を上げるには、Groovyの機能を把握する必要があります現在、Java Closuresなど）の一部ではありません。別の違いは、フレームワークがコードを生成する哲学です。Grailsは実行時に多くのメソッドを生成します。 Rooには、アスペクト指向プログラミングの使用に関するマジックの裏側がなく、Rooが生成するすべてのコードを表示できます。たとえば、Rooでは、findByBook（）などの動的Finderメソッドを生成するコマンドを使用する必要があります。 .ajファイルで生成されたコードを表示するGrailsでは、実行時にfindByBook（）メソッドが作成されるため、生成されたコードを表示することはできません。すべてのthをマージすることによるアプリケーション通常の.Javaファイルにコードを生成します。これにより、実行時または設計時に、Rooライブラリに依存しなくなります。 Grailsが気に入らないと判断した場合、機能するアプリケーションを使い続けながらフレームワークの使用を停止する方法はありません。
IMOと2つはあまり似ていません。類似点はありますが、次の点が重要な違いです。
- Rooは「Stock-Standard Java」を使用し、GrailsはGroovyに基づいています
- GrailsはWebフレームワークですが、Rooはそうではありません
RooはGrailsのコマンドラインシステムに非常に似ています（例：create-app、create-domain-class、test-app Grailsにあるコマンドを入力します）。 Grailsフレームワークのこの部分とRooの間に「相互受粉」が見られることは驚くことではありません。
SpringSourceのBen AlexがRooについて このインタビュー で語り、Grails対Rooについて尋ねられます。異なる言語を使用すること以外の主な違い（Groovy vs Java他の人が述べたように））は、主にRooが開発時ツールであり、Grailsがランタイムにより関与していることです。
実際にはそれほど似ていません。 Rooはコンパイル時に魔法を使いますが、Grailsはそれを実行時に行います。そのため、Rooプロジェクトは実行時にパフォーマンスに影響を与えません。
GrailsはJavaのGroovyとRooに基づいて構築されているため、それらをどのように統合できるかわかりません。
Grailsのメーリングリストには、RooはGrailsへの足がかりとしてのみ存在すると著者が信じていることを示すコメントがいくつかありました。しかし、私は個人的にGrailsからRooへの切り替えを検討しています。主な違いは、動的型付け言語と静的型付け言語の違いだと思います-私にとってこれは巨大です。私はGrailsの多くの機能を愛していますが、静的に型付けされた言語のIDEサポートおよびコンパイル時チェックを好みます。現在大規模な開発が行われているので、誰が将来の可能性を知っているのか。
実稼働環境にアプリケーションがあり、Spring MVCで開発されたという要件があり、新しい機能の開発速度は遅かった。 GrailsやRooなどの代替フレームワークを調査する必要がありました。個人的には、どちらが良いかを調べるのに1か月近く費やしました。
分析の詳細をご覧になりたい場合は、@ http://krishnasblog.com/2012/05/08/roo-vs-grails/ にアクセスしてください。
これらと以下の両方で次の機能を調査しました。最終判断では、どちらを使用するかはわかりませんが、まだ調査中です