SpringSource (maintenant VMWare) possède deux technologies très similaires : Grails et Spring Roo. J'ai utilisé Grails, mais je vois que SpringSource travaille activement sur quelque chose qui est un concurrent de cette technologie et cela m'inquiète pour l'avenir de Grails.
Quelqu'un sait-il comment ces technologies sont liées, vont-elles être fusionnées ou l'une d'entre elles sera-t-elle abandonnée ?
Par ailleurs, existe-t-il des différences techniques importantes entre Grails et Roo ?
SpringSource L'objectif de Spring est de rendre la construction, l'exécution et la gestion des solutions basées sur Spring aussi rapides et faciles que possible. Nous avons à la fois Grails y Spring Roo parce que la productivité des développeurs nous tient à cœur et qu'il est indéniable que ces deux outils donnent un sérieux coup de pouce à ce que les équipes peuvent réaliser avec Spring.
Nous disposons des deux technologies car Roo et Grails sont très différents au niveau de la philosophie et de la mise en œuvre (comme déjà noté dans les autres réponses). Chaque technologie aborde son langage principal (Java ou Groovy) et son modèle d'exploitation (dev-time ou runtime) avec la philosophie suivante : "Comment rendre la proposition de valeur incroyablement bonne en utilisant cette combinaison de langage et de modèle d'exploitation ? Ainsi, vous verrez chaque technologie adopter un style différent qui maximise cette combinaison (Java+Dev-time de Roo ou Groovy+Runtime de Grail) et les avantages qui en découlent.
Ces différences sont en fait très positives, car elles signifient que la communauté Spring peut choisir la "saveur" de la solution de productivité qu'elle préfère. Si ces différences initiales autour du choix du langage et du fonctionnement de l'exécution/du développement sont immédiatement apparentes, le choix de Grails ou de Roo s'étend également à des considérations plus subtiles telles que les technologies utilisées par défaut, le modèle d'interaction avec l'utilisateur, le support de l'EDI, les dépendances, les normes, la feuille de route, les extensions, etc. Presque toutes ces différences sont une conséquence naturelle de la recherche de la meilleure solution pour un style de langage particulier.
Notre meilleur conseil est d'envisager les deux solutions. Chacune a ses points forts, mais il existe des différences entre les deux, qui feront que votre expérience globale sera meilleure avec une technologie ou l'autre dans un contexte donné. Les deux guides de référence détaillent les avantages respectifs de chaque solution . Bien sûr, n'oubliez pas que l'investissement en temps est minime pour essayer les deux. En 10 minutes, vous pouvez construire un projet en Roo ou en Grails, alors essayez-les et voyez ce qui vous semble le plus naturel compte tenu de vos antécédents spécifiques et des besoins de votre projet.
La principale différence est que Roo est un framework purement Java, tandis que Grails utilise Groovy ainsi que Java. Tous deux sont construits sur les bibliothèques de base de Spring et utilisent des bibliothèques Java open source populaires.
Cette question a été posée lors de l'annonce de Roo et Graeme Rocher (responsable de Grails) a déclaré que les deux frameworks ont leur place dans Spring et sont pris en charge de la même manière.
Je pense que Grails a un avenir plus prometteur que Roo. J'aime développer avec lui et je ne vois pas d'inconvénient à ce qu'il ne soit pas purement Java.
Grails et Roo sont très différents. La première différence majeure est le langage utilisé. Si vous pouvez écrire du code Groovy comme du code Java traditionnel, vous avez néanmoins besoin des dépendances Groovy pour exécuter les applications Grails. Pour être aussi productif que possible avec Grails, vous devez également maîtriser les fonctionnalités de Groovy qui ne font pas partie de Java, comme les fermetures. Une autre différence réside dans la philosophie adoptée par les frameworks pour générer du code. Grails génère un grand nombre de méthodes au moment de l'exécution, tandis que Roo les génère sur demande au cours du processus de développement. Roo n'a pas de magie en coulisse, sauf pour l'utilisation de la programmation orientée aspect, et vous pouvez voir tout le code que Roo génère. Par exemple, dans Roo, vous devez utiliser une commande pour qu'il génère des méthodes dynamiques de recherche telles que findByBook(), puis visualiser le code généré dans les fichiers .aj. Dans Grails, la méthode findByBook() est créée au moment de l'exécution, et vous ne pouvez pas visualiser le code généré. Roo vous permet également d'arrêter d'utiliser le framework si vous le souhaitez tout en continuant à avoir une application en cours d'exécution en fusionnant tout le code généré dans des fichiers .java normaux. Vous ne dépendez alors d'aucune bibliothèque Roo, que ce soit au moment de l'exécution ou de la conception. Si vous décidez que vous n'aimez pas Grails, il n'y a aucun moyen d'arrêter d'utiliser le framework tout en continuant à avoir une application fonctionnelle.
Nous avons écrit un blog poste à ce sujet qui pourrait intéresser certains
IMO les deux ne sont pas très similaires. Même s'il existe des similitudes, les différences suivantes sont significatives :
Roo est très similaire au système de ligne de commande de Grails (par exemple, la fonction create-app , create-domain-class , test-app de type commandes trouvées dans Grails). Je ne serais pas surpris de voir une certaine "pollinisation croisée" entre cette partie du framework Grails et Roo.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
