Réponses:
IMO, la partie la plus faible de Grails a été le manque de fonctionnalité de migration de modèle de données (ala migrations Rails ActiveRecord). Il y avait des plugins tiers de différents niveaux de qualité, mais rien d'officiel.
Cependant, je viens de découvrir que Liquibase a été étendu et transformé en plugin de migration de base de données, et cela semble prometteur: http://www.grails.org/plugin/database-migration
Sur le plan positif, pour tout ce que j'ai utilisé Grails (applications Web simples à modérément complexes), c'était surtout fantastique. Je dirais que je peux obtenir à peu près une augmentation de 2x à 3x de la productivité de développement sur une pile Java / Hibernate / Spring / Spring MVC.
L'exécution des tests d'intégration a été lente car l'environnement Grails prend du temps à se charger et seule une fraction de ce temps est nécessaire pour exécuter le test. Cela augmentera le délai d'exécution lorsque vous développez du code qui écrit dans la base de données. L'autre problème a déjà été évoqué par Kaleb dans sa réponse (sur la migration des données). J'ai également constaté que chaque fois que j'étais coincé, le nombre de forums où je pouvais obtenir de l'aide était limité par rapport à l'aide disponible pour l'hibernation et le printemps.
Un piège actuel à l'utilisation du cadre est sa mauvaise intégration actuelle dans le système de construction gradle. Il utilise actuellement un plugin pour accomplir cela, mais le plugin lui-même rompt avec les nouvelles versions de Grails (comme j'ai récemment essayé d'utiliser et de corriger). Ils prévoient de résoudre ce problème dans la future version en faisant gradle une partie du système de construction Grails (au lieu de gant), mais l'absence d'un système de construction que vous pouvez facilement intégrer est un problème. Cependant, cet écueil disparaîtra à l'avenir.
Un autre écueil est la nature dynamique de la langue. Vous DEVEZ vraiment écrire des tests pour tout. La plupart des erreurs dans votre code se trouvent lors de l'exécution. C'est vraiment une façon différente de penser un programme. Compter sur le compilateur pour trouver certaines de vos erreurs ne se produit pas avec ce framework. Je ne dis pas que c'est mauvais, c'est juste différent (et un écueil si vous ne le connaissez pas).
J'aime le concept Grails / groovy, même si j'ai personnellement utilisé plus de groovy que de grails, je pense qu'ils sont tous les deux splendides.
Le seul inconvénient (dans mon expérience personnelle) est un mauvais support IDE. Je pensais (plutôt optimiste) que, comme SpringSource avait une excellente construction Eclipse et étaient de fervents partisans de Grails, ce serait la voie à suivre. Les plugins groovy sont difficiles à installer, la complétion du code est floconneuse (toujours un problème avec les langages dynamiques mais me donner un choix de 60 méthodes n'est pas utile), le débogage peut être fastidieux car il nécessite souvent de parcourir le code interne de groovy, et, dans la dernière version, l'installation du plugin groovy casse le débogueur Java!
Actuellement, il supporte mal les classes abstraites. Par exemple, vous ne pouvez pas lier une liste d'implémentations en une seule List<T>dans un objet de commande. Certes, c'est principalement ennuyeux parce que j'ai l'habitude de lier comme par magie tout le reste! :RÉ
En général, c'est toujours un peu "vert"; vous rencontrez finalement de petites limitations et bogues étranges. Cela a vraiment fait du chemin en quelques années.