Spring ROO : Premiers retours


SpringSource nous a fait un cadeau de fin d’année en nous annonçant, le 31 Décembre 2009, la release de la version 1.0.0 de Spring ROO. Pour rappel, Spring ROO est un interpréteur en ligne de commande, dont l’objectif est de vous permettre de développer rapidement des applications standards via de la génération de code. Pour illustrer l’outil, rien de mieux qu’une petite phrase issue de la documentation officielle :

[…] Most of the time you’ll just go about programming in your text editor or IDE as usual. As you make changes to your project, Roo intelligently determines what you’re trying to do and takes care of doing it for you automatically.

J’ai donc profité d’une journée de mauvais temps pour tester un peu tout ça. Ce billet illustre mes retours.

Mes attentes

Mes attentes sur cette étude sur Spring ROO étaient les suivantes :
– Avoir déjà un premier bagage sur les possibilités offertes par Spring ROO
– Etudier les possibilités de customisations de ce générateur de code
– L’idée sous-jacente étant l’industrialisation de mes développements récurrents

Les questions que je me posais en début d’analyse :

ROO est-il transparent dans les devs ? Quelle adhérence a-t-on avec ce dernier ?
Possibilité de customisation des templates utilisés ? (pour la génération d’une Entity par exemple)
Possibilité de rajout des commandes « à nous » pour générer des choses spécifiques à notre domaine fonctionnel ? (notion de « cartridges » en MDA)
Quelle customisation possible sur l’initialisation de projet ? (ex: utilisation d’archetype maven possible ?)
Quel mode de génération ? Plutôt one shot ou incrémental ?
L’outil peut-il être utilisé dans une approche itérative de type MDA ?

Les réponses à ces questions

ROO est-il transparent dans les devs ? Quelle adhérence a-t-on avec ce dernier ?

Dans le source généré : certaines annotations @Roo apparaissent.

L’implémentation de ces annotations est disponible dans une dépendance maven de scope provided (donc non nécessaire au niveau runtime) : l’idée est que ces annotations n’apparaissent plus dans le bytecode générée car remplacées par leur implémentation lors de la compilation.

Des aspects apparaissent également pour rajouter un comportement standard à certaines entités (ex: getters/setters/toString/hashcode sur les Entités, opérations CRUD sur Controller etc…). On pourrait faire un parallèle de ces aspects avec les Stéréotypes UML préconisés dans une approche MDA.

La désolidarisation avec Spring ROO est tout à fait possible à tout moment (une section de la documentation traite d’ailleurs de cette problématique) et il est même possible de rebrancher Spring ROO après s’en être désolidarisé.

Sur cette question, Spring ROO répond complètement !… Et c’est une bonne chose d’avoir posé cette exigence comme base à l’outil.

Possibilité de customisation des templates utilisés ? (pour la génération d’une Entity par exemple)

Alors là, sur cette question, j’avoue avoir été très déçu.
Premièrement par la documentation … complètement vide sur le sujet. Sur ce point, il faut relativiser puisque le projet est tout jeune (le facteur d’adoption risque cependant d’en pâtir !).
J’ai donc dû mettre les mains dans le cambouis pour me faire une idée : j’ai descendu l’ensemble des sources du tag 1.0.0.RELEASE et ait un peu trifouillé à droite à gauche.

C’est alors que je suis tombé sur cette classe de l’add-on entity. Et bien on peut y voir que l’implémentation des différentes méthodes est mise en dur dans le code java (cf chaînes « this. » qui traînent un peu partout).

Donc là, autant vous dire que mes espoirs de customisations, à coup de templating (type velocity), s’envolaient en fumée.

Possibilité de rajout des commandes « à nous » pour générer des choses spécifiques à notre domaine fonctionnel ? (notion de cartridge en MDA)

Sur ce point, je n’ai pas pu creuser profondément le modèle d’addons.

En revanche, l’arborescence utilisée sur le SVN répond un peu à ma question : il devrait être assez facile de rajouter ses propres commandes interprétables en ligne de commandes.

Et ça, c’est plutôt bien ! 🙂

Une seule subtilité toutefois : ROO distingue trois familles d’addons : les addons du noyau (nécessaire pour un bon fonctionnement de Roo), les addons de base (une collection d’addons packagés avec Roo) et les addons tiers (développés par n’importe qui désirant rajouter des fonctionnalités a Roo).

Quelle customisation possible sur l’initialisation de projet ? (ex: utilisation d’archetype maven ?)

Ce point est également délicat. Les informations se trouvent tantôt dans le projet « project » (core addon) tantôt dans le base addon « maven » (on peut, par exemple, y trouver le template du pom.xml du projet généré, ou encore celui du applicationContext.xml).
En revanche, là encore, tout paraît être fait en dur dans les classes java 😦

La grande question reste « pourra-t-on surcharger un addon du noyau dans le futur ? » … pour le moment cela n’a pas l’air d’être possible !

Peut-être est-ce que l’idée serait de travailler « à la » maven en prenant un nom de projet modèle lors de la création du projet (ex: project –topLevelPackage com.tenminutes –projectSkeleton mySkeleton) ?

Quel mode de génération ? Plutôt one shot ou incrémental ? L’outil peut-il être utilisé dans une approche itérative de type MDA ?
Clairement, l’approche de Spring ROO est incrémentale : c’est annoncé dès le début dans la documentation.
Ce qui est intéressant, c’est que l’utilisation de l’interpréteur n’est pas obligatoire : vous pouvez tout à fait rajouter des attribut dans votre Entity, via l’IDE. Lors de la prochaine utilisation de l’interpréteur, ces nouveaux attributs seront reconnus par Spring ROO.

En revanche, contrairement à l’approche MDA où l’information est censée se trouver dans un modèle (ex: modélisation UML) pivot qui permet de générer le code et la documentation (spécifications), l’approche Spring ROO est radicalement opposée : l’information se trouve dans le code java uniquement (charge à vous d’annoter les classes avec vos annotations correspondant à des stéréotypes).
Du coup, je m’interroge sur l’aspect « documentation » de l’outil. Générer une platrée de code, c’est bien… mais comment dialoguer avec le client ? (oui je sais, je suis old school … mais lorsque je travaille avec un client qui spécifie le projet -via UML- et qui n’a pas envie de changer ses process pour faire de l’agile : comment je fais ?).
La sensation globale que ROO m’a laissé est qu’il s’agit là d’un outil encore très très jeune. J’ai l’impression qu’il s’agit là d’un POC plus que d’un réel outillage réaliste pour les développements de tous les jours (cela viendra sûrement avec le temps).
Je note toutefois l’aspect AddOn qui va dans le bon sens (dommage qu’il n’y ait, pour l’heure, aucune documentation sur le sujet !).

Forces & Faiblesses

Allez, pour finir, les forces et faiblesses notées au fil de l’eau pendant cette journée …

+ On peut se désolidariser du fonctionnement de ROO à tout moment
+ Pas de parent sur le pom.xml généré 🙂
+ Une bonne idée : le log.roo qui contient l’historique de toutes les commandes ROO exécutées (et la possibilité de tout rejouer via la commande script)
+ Utilisation d’aspects pour « transformer » les annotation en bytecode java lors de la compilation
+ La génération contextualisée : on génère une entité, on rajoute des champs, on crée une vue ok … puis lorsqu’on rajoute un champ à l’entité, la vue est impactée
– L’utilisation d’aspects risque de compromettre mes besoins… en effet, pour un client qui se trouve dans le domaine bancaire (et qui veut pouvoir auditer son code facilement), ça rend les choses très compliquées. Je garde espoir en me disant que la customisation est suffisament bien faite pour éviter la création d’aspects…
– La doc sur les addons n’est pas encore rédigée … du coup pour se faire une idées des customisations possibles, il faut tomber le source de spring ROO …
– Aouch lorsque je regarde cette classe :  je sens que la customisation va être très compliquée lorsque je vois que le code est géréné en dur dans le code java 😦
Publicités

2 Réponses to “Spring ROO : Premiers retours”

  1. Ben Alex Says:

    Thanks for your thoughts on Spring Roo. It’s good of you to share them with everyone.

    Your main concern seems to surround the documentation and complexity of add-on development. Some third parties have already developed add-ons without documentation, but this is certainly an area we acknowledge needs further improvement and you will notice our efforts in this regard over the next few releases. In the meantime my « Roo deep dive » presentation at http://www.slideshare.net/benalexau/spring-roo-100-technical-deep-dive offers some good background material.

    FYI there were earlier, unreleased versions of Roo. I talk a little about this in the reference guide (« history » section). I mention it because those earlier versions of Roo variously used Velocity or FreeMarker as part of the template generation model. We moved away from this type of templating because most of the complexity is not actually within the « invocable member bodies » (ie constructor or method bodies) but rather in the retrieval and definition of the metadata related to different members (eg the parameterized method arguments, return types, modifiers etc). I couldn’t identify a simple model that would allow such factors to be gracefully expressed via a template, although there are ways to get some of the way there.

    The other reason I didn’t use a template engine in Roo 1.0.0 as released was due to the its comparatively slower performance. Whenever Roo loads it internally regenerates every ITD to determine if it needs to change anything on disk (eg as it was not running while the user changed some part of their project). As such, generation overhead is an important consideration as projects become larger and our present model minimises this overhead.

    Again, thanks for your thoughts on Roo. We do appreciate it.

    Cheers

    Ben Alex
    Project Lead, Spring Roo
    SpringSource – a division of VMware

    • Frédéric Camblor Says:

      Hi Ben,

      It is surprising to see you there !.. How have you reached this all new blog (opened 2-3 days ago) this fastly ? (#roo on twitter ? :-))

      I just took your « Roo deep dive » presentation which pointed to me some keys I hadn’t reached in my first approach !.. With your agreement, I will backtrack this link to my original post since this is really interesting materials.

      Thanks, too, for the precision about the reasons why a templating engine has been abandonned. I understand the first point, but the second (performance point) is not, for me, a key point since some workarounds could be made to avoid this problematic.
      For example, using SHA/MD5 hash in ROO metadata providing 2 informations :
      – has the local « model » file changed since last ROO generation ? (if yes, proceed to next interrogation, if no, no need to inspect anything regarding the given « model »)
      – has the ROO files related to the previous model changed ? (this implies, as you said, re-generation of ITDs to compare with the existing ones)
      Maybe this approach is naive regardless of the reality … but I am persuaded that re-generation could be optimized in lots of manners.

      A last question : do you plan to allow core addons overloading ?
      The main black point I see for now is the hardcoded way to make some task (for example : project creation).
      The archetype approach that maven brings (allowing to say « I want to create a project with skeleton A ») is something largely more flexible than the Roo one … Maybe a simple way to solve this would be to allow addons handles during project creation (this is maybe already the case since we have project core addon which seems to call maven base addon).

      Frédéric


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :