Risposte:
IMO, la parte più debole di Grails è stata la mancanza di funzionalità di migrazione del modello di dati (migrazioni di ala Rails ActiveRecord). C'erano alcuni plugin di terze parti con diversi livelli di qualità, ma niente di ufficiale.
Tuttavia, ho appena scoperto che Liquibase è stato esteso e trasformato nel plug-in di migrazione del database, e questo sembra promettente: http://www.grails.org/plugin/database-migration
Tra i lati positivi, per tutto quello per cui ho usato Grails (app Web da semplici a moderatamente complesse), è stato per lo più fantastico. Direi che posso ottenere all'incirca un aumento da 2x a 3x della produttività di sviluppo su uno stack MVC Java / Hibernate / Spring / Spring.
L'esecuzione dei test di integrazione è stata lenta poiché l'ambiente grails richiede tempo per il caricamento e per eseguire il test è necessaria solo una frazione di quel tempo. Ciò aumenterà il tempo di inversione durante lo sviluppo di codice che scrive nel database. L'altro problema è già stato citato da Kaleb nella sua risposta (sulla migrazione dei dati). Ho anche scoperto che ogni volta che ero bloccato, il numero di forum in cui potevo ottenere aiuto era limitato rispetto all'aiuto disponibile per il letargo e la primavera.
Un ostacolo attuale all'utilizzo del framework è la sua attuale scarsa integrazione nel sistema di costruzione gradle. Attualmente utilizza un plug-in per raggiungere questo obiettivo, ma il plug-in stesso si rompe con nuove versioni di grails (come ho recentemente provato a utilizzare e correggere). Hanno in programma di risolvere questo problema nella versione futura inserendo gradualmente il sistema di compilazione grails (anziché gant), ma la mancanza di un sistema di compilazione che è possibile integrare facilmente è un problema. Tuttavia, questa trappola andrà via in futuro.
Un'altra trappola è la natura dinamica della lingua. DEVI davvero scrivere test per tutto. La maggior parte degli errori nel codice si trovano in fase di esecuzione. È davvero un modo diverso di pensare a un programma. Affidarsi al compilatore per trovare alcuni dei tuoi errori non accade con questo framework. Non sto dicendo che è brutto, è solo diverso (e una trappola se non lo conosci).
Mi piace il concetto di graal / groovy interi, anche se personalmente ho usato più il groovy piuttosto che i graal, penso che siano entrambi splendidi.
L'unico aspetto negativo (secondo la mia esperienza personale) è il scarso supporto IDE. Ho pensato (piuttosto ottimisticamente) che dato che SpringSource aveva un'eccellente build Eclipse ed era un forte sostenitore di Grails, questa sarebbe la strada da percorrere. I plugin groovy sono difficili da installare, il completamento del codice è traballante (sempre un problema con i linguaggi dinamici ma darmi una scelta di 60 metodi non è così utile), il debug può essere noioso in quanto richiede spesso di scorrere il codice interno di Groovy e, nell'ultima versione l'installazione del plugin groovy interrompe il debugger Java!
Attualmente ha il supporto iffy per le classi astratte. Ad esempio, non è possibile associare un elenco di implementazioni a un singolo List<T>in un oggetto comando. Certo, questo è principalmente fastidioso perché sono abituato a legare magicamente tutto il resto! : D
Generalmente è ancora solo una specie di "verde"; alla fine ti imbatti in strani piccoli limiti e bug. Tuttavia, in alcuni anni ha fatto molta strada.