Grails vs Roo - Warum treibt SpringSource zwei sehr ähnliche Technologien?

Question

SpringSource (jetzt VMWare) hat zwei sehr ähnliche Technologien: Grails und Spring Roo. Ich habe Grails benutzt, aber ich sehe, dass SpringSource aktiv an etwas arbeitet, das ein Konkurrent für diese Technologie ist, und das macht mich besorgt über die Zukunft von Grails.

Weiß jemand, wie sich diese Technologien verhalten, ob sie zusammengeführt werden oder einer von ihnen aufgegeben wird?

Gibt es außerdem wichtige technische Unterschiede zwischen Grails und Roo?

Answer 1

SpringSource Ziel ist es, den Benutzern so schnell und einfach wie möglich zu machen, Spring-basierte Lösungen zu erstellen, zu betreiben und zu verwalten. Wir haben sowohl als auch Spring Roo, weil wir uns sehr um die Entwicklerproduktivität kümmern, und ohne Zweifel liefern beide Tools einen echten Schub für das, was Teams zusätzlich zu Spring erreichen können.

Wir haben beide Technologien, weil Roo und Grails auf der philosophischen und der Implementierungsebene sehr unterschiedlich sind (wie bereits in den anderen Antworten erwähnt). Jede Technologie nähert sich ihrer Primärsprache (Java oder Groovy) und dem Betriebsmodell (Laufzeit oder Laufzeit) mit der Philosophie "Wie können wir das Wertangebot mit dieser Sprach- und Betriebsmodellkombination unglaublich gut machen?". Daher wird jede Technologie einen anderen Stil annehmen, der diese Kombination maximiert (Roos Java + Dev-Zeit oder Grails Groovy + Runtime) und die entsprechenden Vorteile.

Diese Unterschiede sind in der Tat sehr positiv, weil sie bedeuten, dass die Spring Community wählen kann, welche "Geschmacksrichtung" der Produktivitätslösung sie bevorzugen. Während diese anfänglichen Unterschiede in Bezug auf Sprachauswahl und Runtime/Dev-Time-Operation sofort offensichtlich sind, erstreckt sich die Wahl von Grails oder Roo auch auf subtilere Überlegungen wie die verwendeten Standardtechnologien, Benutzerinteraktionsmodell, IDE-Unterstützung, Abhängigkeiten, Standards, Roadmap, Erweiterungen usw. Nahezu alle diese Unterschiede sind eine natürliche Folge der Verfolgung einer Best-of-Breed-Lösung für einen bestimmten Sprachstil.

Unser bester Rat ist, beide Lösungen in Betracht zu ziehen. Jeder hat seine Lieblingspunkte, aber es gibt Unterschiede zwischen den beiden, die Ihre Gesamterfahrung mit der einen oder der anderen Technologie in einem gegebenen Kontext verbessern. Beide Referenz-Guides beschreiben die respective benefits von each solution. Denken Sie natürlich daran, dass die Zeit, die Sie investieren, minimal ist. In 10 Minuten kannst du ein Projekt in Roo oder Grails bauen, also versuche es und finde heraus, was sich für dich aufgrund deiner spezifischen Hintergrund- und Projektbedürfnisse natürlicher anfühlt.

Answer 2

Der Hauptunterschied ist, dass Roo ein reines Java-Framework ist, während Grails sowohl Groovy als auch Java nutzt. Beide basieren auf den Spring-Kernbibliotheken und verwenden beliebte Java-Open-Source-Bibliotheken.

Diese Frage wurde zurück gestellt, als Roo angekündigt wurde und Graeme Rocher (Grails Leitung) sagt, dass beide Frameworks einen Platz innerhalb Spring haben und gleichermaßen unterstützt werden.

Wenn überhaupt, denke ich, dass Grails eine bessere Zukunft hat als Roo. Ich liebe es, mich damit zu entwickeln und sehe keine Nachteile darin, dass es kein reines Java ist.

Answer 3

IMO die beiden sind nicht sehr ähnlich. Auch wenn es Ähnlichkeiten sind folgende signifikante Unterschiede:

• Roo verwendet "Aktien Standard-Java", Grails basiert auf Groovy
• Grails ist ein Web-Framework, ist Roo nicht

Roo ist dem Kommandozeilensystem von Grails sehr ähnlich (zB die create-app, create-domain-class, test-app Befehle in Grails). Es würde mich nicht wundern, wenn ich zwischen diesem Teil des Grails-Rahmens und Roo eine "Fremdbestäubung" sehen würde.

Answer 4

Ben Alex von SpringSource spricht über Roo in this interview und er wird nach Grails vs Roo gefragt. Der Hauptunterschied neben der Verwendung verschiedener Sprachen (Groovy vs Java, wie andere erwähnt haben) ist, dass Roo hauptsächlich ein Entwicklungszeitwerkzeug ist und Grails mehr in die Laufzeit involviert ist.

Answer 5

Sie sind eigentlich nicht so ähnlich. Roo macht seine Magie zur Kompilierzeit, wo Grails es zur Laufzeit tut. Aus diesem Grund nimmt Roo projects zur Laufzeit keine Performance-Hits.

Ich kann nicht sehen, wie sie zusammengeführt werden konnten, wie Grails auf Groovy und Roo auf Java gebaut wird.

Answer 6

Grails und Roo sind sehr unterschiedlich. Der erste große Unterschied ist die verwendete Sprache. Während Sie Groovy-Code wie traditionellen Java-Code schreiben können, benötigen Sie die Groovy-Abhängigkeiten, um Grails-Anwendungen auszuführen. Um in Grails so produktiv wie möglich zu sein, müssen Sie auch Funktionen in Groovy kennen, die derzeit nicht Teil von Java sind, wie Closures. Ein weiterer Unterschied ist die Philosophie, die die Frameworks bei der Codeerstellung verfolgen. Grails erzeugt zur Laufzeit eine Vielzahl von Methoden, während Roo diese während des Entwicklungsprozesses auf Anfrage generiert. Roo hat keinen Hintergrund für die Verwendung von aspektorientierter Programmierung und Sie können den gesamten Code, den Roo generiert, anzeigen. Zum Beispiel müssen Sie in Roo einen Befehl verwenden, um dynamische Suchmethoden wie findByBook() generieren zu lassen und dann den generierten Code in den .aj-Dateien anzuzeigen. In Grails wird die Methode findByBook() zur Laufzeit erstellt, und Sie können den generierten Code nicht anzeigen. Roo ermöglicht es Ihnen auch, das Framework zu beenden, wenn Sie eine laufende Anwendung verwenden, indem Sie den generierten Code in normale .java-Dateien zusammenführen.Sie haben dann weder zur Laufzeit noch zur Entwurfszeit Abhängigkeiten von irgendwelchen Roo-Bibliotheken. Wenn Sie Grails nicht mögen, gibt es keine Möglichkeit, das Framework zu beenden, während Sie weiterhin eine funktionierende Anwendung haben.

Answer 7

Ich habe einige Kommentare zu den Grails-Mailinglisten gesehen, die darauf hindeuteten, dass die Autoren der Meinung waren, dass Roo nur als Sprungbrett zu den Grails existiert! Ich persönlich überlege mir aber einen möglichen Wechsel von Grails nach Roo. Ich denke, der Hauptunterschied zwischen dynamischen und statisch getippten Sprachen ist für mich enorm. Ich liebe viele Funktionen von Grails, aber ich bevorzuge die IDE-Unterstützung und die Kompilierzeitprüfung einer statisch getippten Sprache. Einige andere fühlen genau das Gegenteil, daher Pferde für Kurse. Statisches Groovy wird derzeit jedoch stark weiterentwickelt. Wer weiß, was die Zukunft bringt?

Answer 8

Wir hatten eine Anforderung, wo wir eine Anwendung in der Produktion hatten und in Spring MVC entwickelt wurden und die Geschwindigkeit der Entwicklung neuer Features war langsam. Wir mussten alternative Frameworks wie Grails und Roo erkunden. Ich persönlich verbrachte fast einen Monat damit, herauszufinden, welches besser war.

Wenn Sie @ die Details der Analyse Besuch sehen wollen http://krishnasblog.com/2012/05/08/roo-vs-grails/

Wir erkundeten diese beiden folgenden Merkmale und unten ist unsere Ergebnisse. Das endgültige Urteil wir sind nicht sicher, ob wir eines verwenden werden, wir sind immer noch auf der Suche