Spring ROO, générateur d’applications JEE

Real Object-Oriented

ROO, c’est un générateur d’application JEE en mode ligne de commande, qui veut offrir une approche inspirée des meilleures pratiques retenues par Spring et offrir une grande productivité. Son positionnement en fait un candidat sérieux aux outils de mise en place technique d’un projet.
(Remarque : La version utilisée dans cet article est la 1.1.2.)

Console Roo sous Eclipse

La console ROO sous Eclipse (STS)

Principes généraux

L’architecture est structurée selon les principes suivants :

  • Concision du code, par l’usage intensif d’aspects (avec AspectJ) ;
  • Affranchissement de la couche DAO, les instructions de persistance étant rattachées aux entités
    • on appelle par exemple Utilisateur.findUtilisateur(id)
    • ou bien utilisateur.persist();
  • Découplage du code généré et du code modifié, pour continuer à utiliser les lignes de commande après implémentations des spécificités du projet ;
    • Le code généré est maintenu dans les classes d’Aspect,
    • Le code personnalisé est intégré aux .java à la main du développeur.
  • Ouverture technologique, grâce à un portefeuille de plugins richement doté, et appelé à être complété au vu des développements en cours (JSF 2.0, JAXB,Vaadin,Wicket…),
  • Approche Top-Down du modèle : la génération de la base de données se fait à partir de la configuration JPA des classes métier.

Un portefeuille d’extensions riche

En termes de librairies et d’outillage, c’est du classique quand on est dans l’écosystème Spring :
Maven, JPA, Spring MVC+ Security ,…
Les bases de données couvertes sont: DB2, ORACLE, MYSQL, H2, POSTGRES…, et dernièrement, Google App Engine !

Certains choix techniques sont en cours de changement, Dojo est appelé à être remplacé par jQuery dans la version 1.1.3.

Pour ce qui est de la persistance, le choix est donné pour l’implémentation de JPA : Hibernate, EclipseLink, DataNucleus…

De même, pour la présentation, on peut choisir entre Spring MVC associés à des JSPs ou bien GWT.

Prise en main & Utilisation

L’intégration dans STS (déclinaison d’Eclipse à la sauce Spring) est tout à fait opérationnelle, et même sympathique, grâce à une complétion conviviale et un accès à l’historique des commandes.
Le cloisonnement entre le code écrit et celui généré en lignes de commande est particulièrement efficace, sur les parties Modèle et Contrôleur.

Enrichissement de la classe modele

Enrichissement de la classe modele : JSON et JPA

Ce cloisonnement est plus sensible pour le code des tests en selenium ; on gardera à l’esprit qu’il vaut mieux demander à Spring ROO de générer les scenarios de tests après avoir stabilisé le développement du modèle.

Comportements relevés au fil de l’utilisation de ROO

Concernant GWT, le plugin nous a apporté quelques désagréments…. ayant conduit à l’abandon de cette approche, pour l’instant tout du moins; du code GAE est généré systématiquement, à tort (correction attendue en 1.1.3).

De plus, Il faut noter que l’approche par AspectJ limite fortement la pertinence des tests de couverture, nous n’avons pas trouvé à ce jour le moyen de faire passer Cobertura dans les aspects… et ils sont nombreux avec Spring ROO.

Certaines extensions sont seulement intégrées pour amorcer les développements, notamment l’utilisation de Spring Web Flow, qui est un simple outillage du projet pour amorcer des développements à la main.

En revanche, l’approche REST associée à la génération simplifiée de code JSON (basée sur flexjson), plaide beaucoup en faveur de ROO quand il s’agit de mettre rapidement en place un backend de données, pour vos développements Mobile par exemple.

Utilisation de Selenium

L’outillage du projet avec selenium est intéressant. On pourra toujours gloser sur l’intérêt de tester ‘fonctionnellement’ des écrans qui sont surtout d’ordre ‘gestion de tables de référence’, mais on dispose en l’état d’une première brique opérationnelle pour notre campagne de tests :

Commande Roo Selenium

Ajout de scripts Selenium à un contrôleur Spring MVC

Que l’on lance dans la fenêtre de commande avec :
mvn selenium :selenese
A noter que si on ajoute un champ dans l’entité Appartement, le script selenium n’est pas impacté et l’exécution suivante tombe en erreur…. Il vaut mieux construire ses tests en fin de cycle, autant que possible.

De plus, les données en base ne sont pas nettoyées à chaque cycle. il faudra introduire un mécanisme de nettoyage ou de remise à niveau de notre jeu de test. On a l’assurance de pouvoir intégrer sans efforts les scripts générés grâce au plugin Selenium de FireFox dans le portefeuille de tests du projet ; mais dans ce cas, nous avons commencé à basculer vraiment vers le cœur de notre projet.

Quelques avertissements et précautions

ROO souffre encore de certains défauts de jeunesse qui, sans remettre en cause son utilisation, doivent conduire à prendre quelques précautions :

  • Les tests unitaires plantent à l’exécution (ceux de type ‘tests mock’) ;
  • Les relations ManyToMany ne sont pas correctement intégrées dans les JSPs ;
  • L’annotation @NotNull a provoqué des plantages d’écrans spectaculaires ;
  • Et quelques autres…

Mais la communauté est active et les versions se succèdent à un rythme soutenu.
On bénéficie en tout état de cause d’un référentiel de bonnes pratiques.