Grails (maintenant) en vaut-il la peine?

J’utilise Grails depuis plus de 4 mois et je vais essayer de vous faire part de mon expérience personnelle et de son utilisation.

Est-ce que Grails en vaut la peine vs Ruby ou autre?

Bien sûr, la réponse n’est pas «oui» ou «non», mais cela dépend . Cela dépend de vos besoins (avez-vous besoin d’être dans le monde Java?), De vos préférences (préférez-vous le développement orienté domaine, préférez-vous Groovy …)? Cependant, je peux répondre que Grails est une alternative sérieuse aux Rails. Je crois que quelle que soit votre application Rails, vous pouvez également le faire avec Grails. Mais selon la nature de votre projet, cela peut prendre plus ou moins de temps. Encore une fois, si vous connaissez Rails mais pas Grails, Rails est l’option la plus sûre.

A-t-il surmonté son buggy start?

Oui Si vous jetez un coup d’œil à mes premiers messages (sur ce site ou sur d’autres sites), je me plaignais beaucoup des bogues de Grails. Mais, il vous suffit de vous rappeler que Grails est un peu rude (pas trop d’utilisation de l’inheritance de domaine, par exemple) et une fois familiarisé avec le framework, vous ne rencontrez pas trop de mauvaises sursockets. Je ne dis pas que Grails n’est pas un buggy. C’est certainement plus que Rails. Mais aussi, il est plus utilisable que le buggy . Un conseil pour cela: utilisez le moins de plugins possible . Parce que beaucoup d’entre eux sont bogués et que certains ne sont pas compatibles entre eux. Donc, n’incluez pas le plug-in grails à moins que vous ne soyez certain que le plug-in grails est à jour, non intrusif et testé (par vous-même).

Est-ce que cela confère vraiment des avantages de développement rapides?

Oui Vous n’avez presque pas besoin de gérer la conception de firebase database. La configuration est presque terminée pour vous depuis le début grâce à Convention over Configuration. Votre application est facilement maintenable. Le seul inconvénient que je vois est le développement frontal qui n’est pas aussi riche que d’autres technologies (comme Rails ou ASP)

Est-ce qu’il fonctionne pour les applications de production du monde réel?

Je ne peux pas dire parce que je ne suis toujours pas allé sur mon site Web, mais je suis assez confiant puisque sky.com utilise Grails et que les sites attirent un trafic important – environ 7 millions de pages vues par jour . Là encore, les performances dépendent beaucoup de l’architecture de votre application et des décisions de conception.

Le plug-in Eclipse est-il meilleur et convenait-il?

Aucune idée. J’utilise IntelliJ mais je suppose que ce n’est pas beaucoup mieux qu’il y a un an, selon les messages de plainte que je vois sur le royaume de Grails.

J’espère que ça aide.

A commencé un projet Rails récemment, avait fait des trucs avec Grails.

Mon principal atout avec Rails est qu’il ya beaucoup de choses complètement opaques avec le dev (que je déteste), et cela a tendance à augmenter lorsque vous commencez à append plus de plugins / generators / libs / etc, car pour les combiner vous devrez réparer quelque chose. Vous avez l’impression que les rails + plugins ne sont qu’un hack géant de DSL qui commence à se briser si vous utilisez une mauvaise combinaison de plugins et de versions .

Avec Grails , bien que l’écosystème soit beaucoup plus petit, tout a tendance à être relativement cohérent. L’approche DSL n’est pas très utilisée, et en utilisant une conception conventionnelle mais ennuyeuse (je veux dire en utilisant des classes, des interfaces, etc. au lieu de DSL), il est beaucoup plus facile de comprendre le fonctionnement de la plomberie.

En procédant à une comparaison 1: 1, voici comment ça se passe:

• Implémentation linguistique : je préfère Ruby over Groovy, même si je ne connais pas bien Ruby. Groovy se sent comme un langage de bonne-intention-mauvaise-implémentation, où certaines des fonctionnalités sont soudées en plus de la syntaxe. Je parle de certaines classes spéciales qui semblent être là uniquement pour permettre un certain piratage.
• Caractéristiques du framework : Rails est bien en avance sur celui-ci. Vous pouvez configurer la plupart des aspects de Rails (par exemple, les mises en page, la création de modèles, les packers css / js, la validation, les frameworks de test, etc.) de plusieurs manières. Grails est à la traîne, bien que ce soit assez flexible pour la plupart des cas d’utilisation.
• Plugins : Rails a une tonne de plugins qui peuvent être considérés comme une bénédiction ou un cauchemar. Certains plugins ne sont pas maintenus, d’autres ne fonctionnent pas bien avec certaines fonctionnalités ou plugins et il y a beaucoup de forks. J’apprends à coller avec les plugins basiques et les plus utilisés (authlogic, haml, etc.) Grails a d’excellents plugins pour les bases (autorisation / authentification, ORM, etc.) et quelques autres plugins pour des choses plus petites
• Tester : Rails a beaucoup de façons de tester, mais ce n’est pas forcément bien. Certains frameworks de test ne fonctionnent pas bien avec certains plugins, etc. Grails dispose de moins de plugins de test, mais encore une fois, ils ont tendance à mieux s’intégrer avec certains des plugins principaux (car il n’y a pas beaucoup de plugins à intégrer)
• Base de données : Grails gagne de loin .
  • Je préfère modéliser mes classes de domaine au lieu de pirater ma firebase database.
  • Hibernate (qui est utilisé sous le capot) est loin de son homologue Rails. Bien qu’il y ait datamapper pour Rails (qui est plus similaire à Hibernate qu’ActiveRecord), je pense que ce n’est pas assez mature. Les Grails ont également des migrations via un plugin.
  • Vous avez d’excellentes implémentations de cache pour Hibernate (cache JBoss, EhCache, etc.) qui peuvent améliorer vos performances sur le toit
• Bibliothèques : Je pense que Ruby a beaucoup de bibliothèques pour de nouvelles fonctionnalités telles que les services NoSQL ou Cloud, tandis que Java possède un grand nombre de bibliothèques pour les anciennes fonctionnalités telles que le traitement Excel. N’oubliez pas que les bibliothèques Java sont généralement beaucoup plus rapides que Ruby
• À la pointe : Rails fait plus de bruit, ce qui se traduit par plus de ressources. Cela signifie que si vous essayez d’intégrer MongoDB ou Riak avec Rails, il y a un bon changement que quelqu’un a déjà fait. Grails est à la traîne, principalement parce qu’il n’est pas très populaire, de sorte que la communauté a tendance à se concentrer sur la résolution des problèmes quotidiens au lieu d’utiliser toutes les fonctionnalités de pointe comme NoSQL, etc.

Voici un exemple:

• La plupart des plugins Grails génèrent du code sous la forme de modèles et / ou de services. Le rest est généralement géré par une bibliothèque. Vous pouvez inspecter le code du modèle / service, voir ce qu’il fait et le modifier.
• La plupart des plug-ins Rails se connectent généralement avec l’API Rails, ce qui signifie que vous finissez par appeler une fonction ou inclure un module, puis utilisez le DSL du plug-in. Cela fonctionne très bien quand ça marche , mais quand ça casse c’est horrible et que vous finissez par devoir patcher des choses ou installer une version de plugin ou de plugin différente. J’imagine qu’un développeur de Rails plus expérimenté est plus à l’aise avec ça mais je ne le suis pas.

Conclusion:

• Si vous voulez être à la pointe de la technologie, ne vous souciez pas des correctifs occasionnels, privilégiez une grande communauté et / ou ne vous souciez pas de la firebase database de style ActiveRecord, optez pour Rails . En outre, Ruby en tant que langue est très élégant
• Si vous préférez les conceptions d’interfaces de classes au lieu de DSL, préférez modéliser votre application via des modèles, ne nécessitant pas de fonctionnalités exquises et maîsortingsant l’écosystème Java, optez pour Grails

Cela en vaut la peine!

Nous utilisons Grails dans plusieurs projets, tous avec beaucoup de succès pour les raisons suivantes:

• Facile – C’est l’un des frameworks les plus simples que nous ayons jamais utilisés

• Réutilisation du code hérité – Tout ce que nous avons à faire est d’obtenir notre code hérité et de le lancer dans le dossier lib ou src et c’est fait. Tout simplement génial pour nous.

• Structure de firebase database héritée – C’est un outil génial si vous souhaitez générer des visualisations de données sur des bases de données héritées.

Maintenant, à propos de la viabilité:

• Bugs: nous n’avons pas rencontré trop de bogues depuis la version 1.1 (la version 1.0 était trop difficile pour nous)

• Outils: Netbeans s’améliore vraiment sur ce front, mais il n’est même pas proche d’autres outils comme Intellij IDEA (un excellent support!). On peut en dire autant d’Eclipse.

• Portabilité: nous n’avons jamais rencontré un seul problème sur nos projets.

Nous avons déjà une demi-douzaine d’applications Grails en production, et bien que Grails soit différent des frameworks Java et nécessite un certain temps d’apprentissage, il a été payant car nous avons utilisé des techniques Agile. Détails:

• Nous utilisons IntelliJ. Ce n’est pas très cher et a été remboursé en quelques semaines pour nous.
• Les tests automatisés, l’continuous integration et le refactoring sont indispensables, comme pour tout code de langage dynamic. Si vous pratiquez déjà TDD ou avez au moins une couverture de code de test correcte, cela n’ajoute pas de travail supplémentaire.
• Hibernate est livré par défaut avec Grails, mais vous pouvez utiliser d’autres frameworks de persistance. Il y a 5 plugins de persistance autres disponibles aujourd’hui
• L’enregistrement n’était manifestement pas une préoccupation dans l’esprit de Graeme Rochers, mais il s’est progressivement amélioré. Je n’ai pas rencontré un problème où une erreur n’a pas été enregistrée, mais (vous devez vous assurer que vous attrapez correctement les exceptions dans votre code)
• Le débogage n’était clairement pas sur le radar (mais cela ne s’est pas amélioré). Nous ne comptons pas sur le débogage de toute façon.

Cela dit, comme avec toutes les nouvelles technologies, je vous recommande de faire des prototypes, des revues de code, de programmer des paires et peut-être aussi de consulter.

Cela en vaut vraiment la peine. Je l’utilise depuis plus d’un an maintenant et j’adore ça. J’avais l’habitude de ne pas utiliser ces outils rad, mais cela a changé ma façon de travailler. Avec la version 1.2, il s’est encore amélioré avec de meilleures informations de trace de stack (en particulier pour les GSP).

Le seul problème que j’ai eu avec la mise à l’échelle a été l’hibernation et son cache, ce qui n’est vraiment pas un problème de grails. Même ceux que je n’aime pas hibernate en général, la façon dont le graal est enveloppé avec GORM est une œuvre d’art pour moi. L’aspect fermeture des critères est merveilleux pour travailler avec.

Je n’ai pas encore trouvé quelqu’un qui est expert à la fois Grails et Rails et préfère Grails.

Si vous connaissez bien les deux, alors vous préférez certainement Rails.

Grails attire généralement les développeurs Java qui craignent un changement de plate-forme.

Dans ce cas, je pense que JRuby est probablement une meilleure façon d’adopter une approche agile sur l’ancienne version de jvm.

Ayant récemment utilisé Grails pour un projet, je souhaite partager nos expériences par rapport au développement d’applications J2EE standard.

Est-ce que cela confère vraiment des avantages de développement rapides?

Certainement, c’est le cas. Même si le chemin d’échafaudage est abandonné tôt et que les conventions ont priorité sur les besoins propres, la période de démarrage est très courte, car nous n’avons pas à nous soucier de nombreuses technologies différentes. Ce type de légèreté nous permet de travailler non seulement plus rapidement, mais aussi plus précisément et plus proprement.

Ecrire des balises n’a jamais été aussi facile – alors que JSF s’est d’abord demandé si cela en valait la peine, avec Grails, nous le faisons tout simplement. Travailler de manière testée et atteindre un taux de couverture élevé est également très facile, même si les différents scénarios de test et stratégies de simulation sont parfois incohérents et bogués.

Passer de Java à Groovy est un grand plaisir, nous adorions avoir des littéraux, des fermetures, des constructeurs, des listes et des cartes, pour jeter notre implémentation de cartes en Java et écrire du code compact, significatif et ciblé.

Ce qui ralentit la vitesse de développement est le support IDE pas si parfait, qui vaut également pour le plug-in IntelliJ, que nous utilisons. La mauvaise documentation, souvent ancienne et même erronée, dispersée à différents endroits (déjouant la promesse “la recherche est terminée”) entrave aussi le développement rapide. Nous avons donc souvent dû recourir à la lecture du code source – par la suite effrayés par les hiérarchies de classe Spring sous-jacentes.

Le débogage est vraiment difficile. Je n’ai jamais trouvé cela être un gros problème. Vous pouvez soit attacher un débogueur et parcourir, soit coller une charge de println / logs dans le code pour déterminer ce qui se passe.

La journalisation est franchement affreuse. Je suis d’accord que les traces de stack fournissent généralement 4 pages d’informations inutiles, avec une ligne occasionnelle qui est informative. Cependant, c’est un petit prix à payer pour un cadre aussi impressionnant.

L’IDE STS Eclipse est de valeur marginale. Eclipse a pissé un mauvais soutien pour Grails. Utilisez IntelliJ si possible. Je suis un serré, mais si mon entreprise me le permettait, je paierais volontiers l’argent pour IntelliJ.

J’utilise Grails depuis les tout premiers jours en 1.0-beta et je ne peux que vous recommander de commencer à prendre Groovy / Grails au sérieux si vous venez de la boutique Java.

Si vous êtes un magasin Java et que vous considérez Ruby Rails, arrêtez Grails. Si grails ne fonctionne pas pour vous, vous pouvez toujours démarrer Rails.

Je partagerai mon expérience de trois ans en utilisant Grails dans presque dix applications. Je ne peux pas comparer avec Ruby on Rails alors je vais répondre à vos autres questions.

A-t-il surmonté son buggy start?

• Oui il a J’ai rencontré quelques bugs Grails sur Grails 2.0.4 / 2.2.4.

Est-ce que cela confère vraiment des avantages de développement rapides?

• Il est assez simple d’apprendre, facile à développer, jamais vu quelqu’un avec une bonne connaissance du monde Java prendre plus d’une semaine de travail pour connaître les bases. Aussi facile à entretenir. Et vous n’avez pas à vous soucier de votre DB – assurez-vous simplement que

Le plug-in Eclipse est-il meilleur et convenait-il?

• Choisissez votre IDE très attentivement. Eclipse m’a beaucoup aidé, mais il plante et cause plus de problèmes qu’il ne le devrait. Je suis allé pour IntelliJ et au cours du mois d’essai, cela semblait être un meilleur choix. Dernièrement, j’ai utilisé Sublime Text, quelques plugins et l’ancienne ligne de commande. Je ne vais à un IDE que dans des situations particulières – pour utiliser son débogueur, par exemple.

Est-ce qu’il fonctionne pour les applications de production du monde réel?

• C’est un peu lourd. Recherchez beaucoup sur vos choix de conception AVANT d’écrire vos modèles. Faites beaucoup de recherches sur le bon design Grails. La plupart des choses que j’ai faites il y a deux ans, je peux réaliser comment le rendre meilleur maintenant depuis que je suis plus expérimenté. Il gère bien les applications de production du monde réel, mais selon les erreurs que vous faites, Hibernate peut vraiment être un casse-tête.

Le plug-in Grails Eclipse est de la merde. Il plante sans raison et ne supporte pas vraiment la flexibilité de Groovy. NetBeans et IntelliJ seraient beaucoup mieux, mais je ne les ai pas encore essayés.

Est-ce qu’il fonctionne? Bien sûr que oui. Même Ruby on Rails fonctionne, tant que vous lancez suffisamment de serveurs sur le problème. Je ne sais pas comment Grails se compare aux différents frameworks Java.

Est-ce que cela confère vraiment des avantages de développement rapides? Bon, il me manque encore beaucoup de bonnes choses Ruby / Rails. Il ne reconnaît pas les parameters de requête Date et Enum automatiquement (encore une fois, Rails a également des problèmes avec les dates), TimeCategory devrait faire partie de la configuration standard mais ne l’est pas. Mais il y a aussi beaucoup de choses qui nécessitent une configuration remarquablement réduite.

Ce n’est pas tout à fait le cas pour Rails (j’ai particulièrement hâte à Rails 3), mais il est beaucoup plus agréable de travailler avec de nombreux frameworks Java. Malgré tout, la magie sous la surface va beaucoup plus loin que dans Rails. Par exemple, le système de Contraintes est très puissant, mais construit sur une énorme couche de trucs de spring impénétrables, et vraiment inflexible si vous souhaitez utiliser cette même puissance de manière légèrement différente. Rails est plus facile à corrompre, IME.

Est-ce que ça vaut le coup? Oui. Est-ce un meilleur choix que quelque chose d’autre? Ça dépend.

Je vous suggère d’essayer pour vous-même. J’aime la flexibilité de Grails et la vitesse de développement. Cependant, comme vous pouvez le voir, l’expérience des autres personnes diffère. Je veux pouvoir développer des applications rapides pour mes clients en utilisant la plate-forme Java et j’ai trouvé que Grails fonctionnait très bien pour nous.

J’ai aussi trouvé le frontend très flexible à développer. Je pense aussi que vous devez faire preuve de bon sens et choisir soigneusement vos plug-ins. Je m’en tiens aux plugins supportés par springsource.

Dans mon expérience, Grails apporte quelques fonctionnalités très intéressantes sur la table, ce qui en fait un outil d’apprentissage et d’utilisation.

• Agilité – ce que nous avions l’habitude de prendre des semaines pour mettre en œuvre des projets J2EE conventionnels, c’est généralement une journée de travail avec le système grails plugin. Des choses comme ajax, jquery ui, acegi, implémentation reposante, système de planificateur et beaucoup d’entre eux
• S’exécute sur JVM, ce qui réduit le besoin d’apprendre un autre système d’exécution et ses particularités

• Java comme la syntaxe et le sucre syntaxique groovy. comme le meilleur des deux mondes. Vous pouvez commencer immédiatement avec Java au lieu d’apprendre la syntaxe d’un nouveau langage comme Ruby, puis, lentement, vous pouvez passer à la syntaxe groovy qui est robuste, facile et intuitive.

  Pour les chefs de projet, à moins qu’il y ait des raisons impérieuses de “ne pas utiliser” les graal pour une raison quelconque (résistance à partir du haut, pour adopter une nouvelle technologie ou autre), je ne vois aucune raison le moins essayé

Pour répondre aux préoccupations concernant le débogage, ce n’est pas si difficile. Le débogage est facile si vous utilisez Netbeans IDE. Cela m’amène à un autre point à mentionner. Après quelques expériences avec tous les IDE, nous avons constaté que Netbeans était le plus approprié pour faire le travail. Il prend mieux en charge l’achèvement du code, la mise en évidence de la syntaxe et le débogage, etc. À mon avis, STS n’est pas suffisant pour cela.

Le plug-in Eclipse est-il meilleur et convenait-il?

Il s’est nettement amélioré au cours de la dernière année. En décembre, j’ai assisté à la Groovy & Grails Exchange à Londres. Il y a eu une bonne discussion concernant l’intégration de Groovy & Grails dans Eclipse / SpringSource STS qui a été enregistrée, voir la vidéo .

De mon sharepoint vue, Eclipse a gagné beaucoup de terrain. Actuellement, IntelliJ semble être un peu en avance, mais cela pourrait changer dans les prochains mois.

En ce qui concerne le plug-in eclipse, il continue à arriver, mais vous pouvez utiliser la version eclipse de Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

C’est assez décent comparé aux versions précédentes des plug-ins, et depuis que Spring Source a acquis la société responsable des grails et des groovy, vous pouvez vous attendre à ce que STS devienne meilleur rapidement

Personnellement, j’ai appris RoR et je l’ai utilisé pour quelques projets domestiques, mais ensuite je suis passé à Grails, principalement parce qu’il fonctionne sur la JVM et j’espère donc pouvoir utiliser la pléthore de programmes de performance / profilage Java, ce qui devrait aider à identifier goulets d’étranglement dans le code avant qu’ils ne deviennent un problème.

En général, je n’ai pas trouvé trop de différence dans la qualité des IDE utilisés par RoR vs Grails. Bien que, pour être juste, je programme sous Linux et je n’ai pas essayé TextMate pour le développement de RoR. Lorsque j’utilisais RoR, j’ai utilisé Netbeans.

En ce moment, je programme en utilisant STS et je trouve que c’est un plaisir à utiliser avec Grails, bien que je trouve toujours que la détection / complétion de la méthode pourrait être améliorée.

Je suis un développeur Java à plein temps, mais j’utilise les rails pour mes projets de loisir. Il y a un an, nous avons évalué les grails pour un projet au travail. Mon expérience avec Grails m’a laissé un peu déçu et c’est la raison pour laquelle j’ai commencé à enquêter sur les rails. Ayant utilisé les deux, mon impression est que, même si groovy n’est pas loin derrière le rbuy en tant que langue, les rails offrent une expérience nettement améliorée sur les grails. Tout simplement, les rails semblent résoudre des problèmes beaucoup plus réels, en particulier lorsque vous tenez compte du nombre de bonnes pierres disponibles. Je pense à des choses telles que la recherche, la gestion des versions, les applications rss, les applications non-crud, l’intégration avec les services cloud, etc. À la fin du mois, les rails 3 auraient dû être libérés. Nous avons en fait décidé d’utiliser maintenant des rails au travail. En fin de compte, le grails est plus facile à prendre en main pour les développeurs Java, mais il manque finalement le raffinement nécessaire pour couvrir un plus large éventail de besoins.

Je dirais non Il est encore trop gonflé, à mon humble avis, pour la plupart des utilisations, surtout si vous voulez juste prototyper quelque chose. Nous n’avons pas besoin de tout ce code, de toutes les dépendances intégrées aux grails pour créer une application Web. Vous n’avez pas besoin de spring à chaque fois que vous souhaitez mettre en place une application Web. Regardez ce que vous essayez d’accomplir avant d’append un monde plein de dépendances à votre stack. Je pense qu’il est important de savoir en quoi consiste votre application.

Je recommande de regarder quelque chose comme le ratpack, qui est beaucoup plus léger, presque comme un sinatra pour le rbuy.

Je tiens à souligner deux autres considérations, l’utilisation de la mémoire et le marché du travail. L’application Grails prend beaucoup de mémoire, notamment en mode de développement, par exemple 600 Mo pour une application de taille moyenne. Lorsqu’il est déployé en mode de production, par exemple un fichier de guerre dans Tomcat, l’utilisation peut être d’environ 500 Mo. Ceci est en partie hérité de l’utilisation de Java.

En ce qui concerne le marché du travail et pour autant que je sache, il y a peu de demande pour les programmeurs Grails dans les annonces de postes vacants, par exemple, Django et Ruby on Rails.

De mon expérience à fin 2013.

Avantages

• Lorsque vous utilisez très peu de plug-ins et que vous limitez un ensemble de no-s et de no-s Grails, l’expérience est plutôt fluide

Les inconvénients

• Le rafraîchissement (F5) est toujours un problème. Et c’est le plus ennuyeux. Pour une raison quelconque, j’ai dû redémarrer le serveur à chaque 3ème et 4ème actualisation. Il y a un bug de redémarrage bien connu: question1 , question2 , bien que cela arrive rarement.
• Bogues au niveau de la langue. Lorsque j’ai utilisé des classes internes statiques, je devais toujours redémarrer le serveur lors d’une modification. Bien qu’il n’y ait pas de problèmes avec la construction, l’utilisation de la langue est limitée pour moi
• temps de démarrage, temps de construction, taille de l’application (70 Mo pour une petite application), utilisation de la mémoire
• débogage à distance uniquement, le débogage IDE est très instable

A-t-il surmonté son buggy start?

C’est toujours horrible. Je ne connais pas leur début, mais la migration de Grails 2 à Grails 3 est toujours un cauchemar et ils brisent plus qu’ils ne résolvent.

Est-ce que cela confère vraiment des avantages de développement rapides?

J’ai passé une heure à faire les tests de Grails pour produire quelque chose dans la console (cela ne fonctionne pas immédiatement), même en Java, vous ne passerez pas autant de temps à sortir quelque chose des tests.

Est-ce qu’il fonctionne pour les applications de production du monde réel?

Je ne connais toujours pas une seule compagnie célèbre qui construit quelque chose avec Grails.

Le plug-in Eclipse est-il meilleur et convenait-il?

Je ne sais pas pourquoi quelqu’un utilise encore Eclipse, mais le support d’IntelliJ pour Grails 3 est tout simplement inutilisable.

Donc, répondant à la question principale:

Grails (maintenant) en vaut-il la peine?

Si vous ne pouvez pas vous permettre la licence Microsoft Access, peut-être. Pour de vrais projets, je restrais loin de Grails. C’est juste un enfant mort-né, en fait.