Encore une bien sympathique rencontre au Groovy Grails User Group hier soir avec les organisateurs et les gugers. Cette rencontre était basée sur l’étude du pourquoi et comment migrer une application web Java standard vers Grails par Stéphane Maldini, qui est au passage commiter sur iceScrum.
J’ai bien aimé la façon dont Stéphane a amené la chose et exprimé le besoin en tant que développeur, de passer à d’autres outils aussi facile d’accès, qu’instinctifs et toujours dans l’esprit de vouloir voir autre chose.
Je ne vais pas passer au crible les différents slides exposés par Stéphane car mon iPhone m’ayant joué des tours, j’ai perdu la moitié de mes notes. Néanmoins, j’ai été un peu étonné par un ou deux argument exposé.
Le premier était que Grails favorise les tests. Je bloque sur ce point et ce, malgré les arguments exposés. En effet, je ne peux comprendre en quoi Grails permet ou facilite l’écriture de tests unitaires. L’idée de Stéphane était que le couple Groovy/Grails permettant un développement plus rapide du code et générant des squelettes de tests, il offre la possibilité au développeur d’utiliser son surplus de temps à l’écriture des tests (sic) !
Le second est qu’il faut abandonner Maven au détriment d’IVY. Cet argument a provoqué une levée de bouclier dans l’assemblée, car bien évidemment, il remet en cause une migration déjà couteuse du SI. Le ressenti de Stéphane vis-à-vis de Maven provenait à priori sur l’aspect normé de Maven, qui impose sa structure de projet. Je pense personnellement, qui faut garder Maven pour les raisons suivantes :
Dommage, que je n’ai pu aller à la troisième mi-temps pour discuter et partager avec les gugers, mais j’espère rectifier le tir à la troisième rencontre !
J’ai bien aimé la façon dont Stéphane a amené la chose et exprimé le besoin en tant que développeur, de passer à d’autres outils aussi facile d’accès, qu’instinctifs et toujours dans l’esprit de vouloir voir autre chose.
Je ne vais pas passer au crible les différents slides exposés par Stéphane car mon iPhone m’ayant joué des tours, j’ai perdu la moitié de mes notes. Néanmoins, j’ai été un peu étonné par un ou deux argument exposé.
Le premier était que Grails favorise les tests. Je bloque sur ce point et ce, malgré les arguments exposés. En effet, je ne peux comprendre en quoi Grails permet ou facilite l’écriture de tests unitaires. L’idée de Stéphane était que le couple Groovy/Grails permettant un développement plus rapide du code et générant des squelettes de tests, il offre la possibilité au développeur d’utiliser son surplus de temps à l’écriture des tests (sic) !
Le second est qu’il faut abandonner Maven au détriment d’IVY. Cet argument a provoqué une levée de bouclier dans l’assemblée, car bien évidemment, il remet en cause une migration déjà couteuse du SI. Le ressenti de Stéphane vis-à-vis de Maven provenait à priori sur l’aspect normé de Maven, qui impose sa structure de projet. Je pense personnellement, qui faut garder Maven pour les raisons suivantes :
- La majorité des SI aujourd’hui travail sous Maven,
- Le mapping du file system Maven sur Grails, n’est pas très couteux,
- Modulo un bon tunning des POM projets et des plugins, on garde la possibilité d'utiliser un maximum de plugin et reporting sur son projet.
Dommage, que je n’ai pu aller à la troisième mi-temps pour discuter et partager avec les gugers, mais j’espère rectifier le tir à la troisième rencontre !
Commentaires
Oui je crois que maven est en effet incontournable dans beaucoup de situations, en particulier dans le cas de la migration, et heureusement grails a un support de maven qui permet de s'y intégrer. En revanche, je sais d'expérience que sur des projets nouveaux ou relativement isolés d'un existant mavenisé la gestion de composants applicatifs sous la forme de plugins grails avec d'ailleurs certains composants mavenisés et une gestion de build par hudson est une façon assez souple de travailler. Dans ce cas précis, lorsque ce type de solution atteint ses limites, j'envisage un mecanisme de build plus systémique avec gradle, toujours avec l'idée de rester proche de l'univers groovy pour privilégier la souplesse.
Cette approche nécessite toutefois un certain rigueur côté tests et je pense que grails offre pas mal de support intéressant pour cela. Cependant pour moi la question sur les tests est plus qu'ils sont obligatoires qu'ils sont plus faciles à traiter.
Volontiers pour échanger un peu plus après la prochaine réunion. Moi même j'ai du partir sans avoir pu vraiment profiter de l'after :)
En effet, je pense aussi qu'il ne faut pas être extrémiste et que dans certaines situations comme du quick&dirty, on peut d'affranchir d'un build Maven. En outre, dans le cadre d'un développement nouveau ou d'un simple module, je pense que Maven peut aider au bootstrap du projet via par exemple, l'utilisation d'un archetype existant ou maison, qu'en penses-tu ?
Ulrich
Merci pour ce billet et ces points de vue intéressant.
Je vais essayer de rebondir sur les deux points qui t'ont un peu étonné.
1- Grails favorise les tests: peut être que le mot favorise n'est pas le mieux adapté, moi je pense plutôt que Grails facilite la mise en place de tests unitaires et d'intégration et offre les contextes nécessaires pour faire ça. A titre d'exemple, on n'a pas à faire une configuration spéciale pour distinguer test unitaires et d'intégration dans un projet mavenisé. On n'a pas besoin non plus de mettre en place une configuration de datasource spécifique aux tests et une autre pour les développements. Dans Grails, tout est prêt.
Je partage aussi l'avis de Louis quand il dit que les tests sont plutôt obligatoires.
2- Concernant l'abandon de Maven au détriment de Ivy, je pense que ce n'est pas très correcte, car Maven et Ivy n'ont comme fonctionnalités communes que la gestion de dépendance. C'est à dire tout ce que peut faire Maven en plus n'est pas offert par Ivy. Donc pour moi la comparaison n'est pas équitable.
D'un autre côté, c'est vrai que c'est une grosse perte d'abandonner Maven surtout s'il est utilisé à tir larigot. Mais commencer une application Grails et la maveniser, encore une fois je ne voit pas l'intérêt, sauf s'il y a des plugins nécessaires et qu'ils n'ont pas d'équivalent dans l'écosystème Grails.
Bon, je reviens au sujet des tests en Grails, je suis entrain d'écrire un billet autour de ce sujet, et j'espère le finir pour te convaincre avec du code plus concret :)
Nabil ADOUANI