Spring Roo

Spring Roo est un outil de création d’application rapide proposé par Ben Alex, l’un des contributeurs de la société SpringSource. Avec une utilisation d’AspectJ très poussée, c’est un environnement de génération rapide, qui propose de construire rapidement une appication Web. Premières impressions et premières réflexions, c’est parti !

Spring Roo est distribué dans Spring STS ou sous la forme d’une archive à installer. Après avoir ajouté le répertoire bin de Spring Roo à votre PATH, vous pouvez alors le lancer en ligne de commande. Celui-ci démarre et propose une interface type terminal toute simple. Imaginez un terminal Linux, où des commandes shells vous permettent de générer le squelette de votre application MVC, vous y êtes. Le code généré est du Java et des fichiers .aj pour la partie Aspect. Les fichiers sont organisés autour d’un projet Maven, ce qui permet de travailler avec son IDE sans problèmes.

L’utilisation de Roo est simple. J’ai trouvé que l’outil en ligne de commande était bien fait. Plus simple à prendre en main que Grails pour les débutants, il vous faudra quelques minutes à peine pour comprendre son utilisation.

Si vous lancez d’ailleurs votre éditeur Java, et que vous laissez Spring Roo en tâche de fond, celui-ci surveille le code source de votre projet. La programmation « roundtrip » est donc possible, modulo le fait que vous soyez obligé de relancer votre serveur web dès que vous modifiez la structure Java. Des annotations placées dans le code permettent de générer des Aspects. Roo utilise AspectJ.

Voici par exemple une class générée avec Roo :

package org.letouilleur.test.domain;

import javax.persistence.Entity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import org.springframework.roo.addon.entity.RooEntity;
import javax.validation.constraints.NotNull;

@Entity
@RooJavaBean
@RooToString
@RooEntity
public class JobPost {

    @NotNull
    private String title;

    private String instructions;
}

Les annotations de Roo sont avec une rétention de type Source. Ce sont donc des annotations qui ne sont utilisées que lors de l’écriture du code dans votre IDE, ou donc via Roo. Cela a pour conséquence que Roo n’est pas une librairie ou un framework à l’exécution. C’est le socle Spring MVC et Webflow, sur une couche JPA ou autre, bref que du classique. Il n’y a pas de dépendances à l’exécution. A part du code source différent, le résultat est donc le même.

Chaque annotation commence par @Roo ce qui permet de les identifier rapidement. De long débat sur l’utilité d’avoir un aspect pour ce qui est toString animent la blogosphère… Moi je dis pourquoi pas ?
Chaque annotation génère un aspect dans un fichier .aj au même niveau que votre classe.

L’annotation @RooToString génère par exemple cet aspect dans un fichier JobPost_Roo_ToString.aj :

// WARNING: DO NOT EDIT THIS FILE. THIS FILE IS MANAGED BY SPRING ROO.
// You may push code into the target .java compilation unit if you wish to edit any member(s).

package org.letouilleur.test.domain;

import java.lang.String;

privileged aspect JobPost_Roo_ToString {
    
    public String JobPost.toString() {
        StringBuilder sb = new StringBuilder();
        sb.append("Id: ").append(getId()).append(", ");
        sb.append("Version: ").append(getVersion()).append(", ");
        sb.append("Title: ").append(getTitle()).append(", ");
        sb.append("Instructions: ").append(getInstructions());
        return sb.toString();
    }
    
}

Finalement, chaque « concern » de mon entité est stocké sous la forme d’un Aspect, au même niveau que celui-ci.

Pas de DAO

Spring Roo suit la même philosophie que Play! Framework, à savoir utiliser le pattern Active Record. Il n’y a pas de DAO, et une explication bien fournie dans la documentation vous explique pourquoi. Encore une fois, c’est plus une approche de développement qu’une histoire de bien ou pas bien.

En quelques mots, comme je vous l’avais montré avec JPA, Spring Roo prend une approche où l’entité n’est pas anémique, mais riche. Chaque entité est capable d’interagir avec la base de données. Vous n’avez pas de DAO, ni de services. Le Controller effectue essentiellement un passage d’argument vers l’entité, qui est celle qui fonctionne avec la base de données.

Pour cela, Roo place dans un aspect tout ce qui est lié à la gestion de la Persistance. Cela permet d’ajouter des finders dynamiques comme avec Grails, chose qui n’est pas possible avec Play! Framework.

Regardez le code de l’aspect JobPost_Roo_Entity.aj :

// WARNING: DO NOT EDIT THIS FILE. THIS FILE IS MANAGED BY SPRING ROO.
// You may push code into the target .java compilation unit if you wish to edit any member(s).

package org.letouilleur.test.domain;

import java.lang.Integer;
import java.lang.Long;
import java.lang.SuppressWarnings;
import java.util.List;
import javax.persistence.Column;
import javax.persistence.EntityManager;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.PersistenceContext;
import javax.persistence.Version;
import org.letouilleur.test.domain.JobPost;
import org.springframework.transaction.annotation.Transactional;

privileged aspect JobPost_Roo_Entity {
    
    @PersistenceContext
    transient EntityManager JobPost.entityManager;
    
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id")
    private Long JobPost.id;
    
    @Version
    @Column(name = "version")
    private Integer JobPost.version;
    
    public Long JobPost.getId() {
        return this.id;
    }
    
    public void JobPost.setId(Long id) {
        this.id = id;
    }
    
    public Integer JobPost.getVersion() {
        return this.version;
    }
    
    public void JobPost.setVersion(Integer version) {
        this.version = version;
    }
    
    @Transactional
    public void JobPost.persist() {
        if (this.entityManager == null) this.entityManager = entityManager();
        this.entityManager.persist(this);
    }
    
    @Transactional
    public void JobPost.remove() {
        if (this.entityManager == null) this.entityManager = entityManager();
        if (this.entityManager.contains(this)) {
            this.entityManager.remove(this);
        } else {
            JobPost attached = this.entityManager.find(this.getClass(), this.id);
            this.entityManager.remove(attached);
        }
    }
    
    @Transactional
    public void JobPost.flush() {
        if (this.entityManager == null) this.entityManager = entityManager();
        this.entityManager.flush();
    }
    
    @Transactional
    public JobPost JobPost.merge() {
        if (this.entityManager == null) this.entityManager = entityManager();
        JobPost merged = this.entityManager.merge(this);
        this.entityManager.flush();
        return merged;
    }
    
    public static final EntityManager JobPost.entityManager() {
        EntityManager em = new JobPost().entityManager;
        if (em == null) throw new IllegalStateException("Entity manager has not been injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?)");
        return em;
    }
    
    public static long JobPost.countJobPosts() {
        return ((Number) entityManager().createQuery("select count(o) from JobPost o").getSingleResult()).longValue();
    }
    
    @SuppressWarnings("unchecked")
    public static List<JobPost> JobPost.findAllJobPosts() {
        return entityManager().createQuery("select o from JobPost o").getResultList();
    }
    
    public static JobPost JobPost.findJobPost(Long id) {
        if (id == null) return null;
        return entityManager().find(JobPost.class, id);
    }
    
    @SuppressWarnings("unchecked")
    public static List<JobPost> JobPost.findJobPostEntries(int firstResult, int maxResults) {
        return entityManager().createQuery("select o from JobPost o").setFirstResult(firstResult).setMaxResults(maxResults).getResultList();
    }
    
}

L’aspect est ajouté sur la classe JobPost. J’ai testé la completion dans SpringSource STS et ça marche plutôt bien. C’est du Grails, avec un typage fort pratique et agréable à utiliser. Avec un Mac, j’ai un peu galéré avec l’outil intégré dans Roo, le Ctrl-Espace ou Pomme-Espace pour la complétion dans STS n’est pas utilisable. Je trouve qu’il est plus pratique de travailler en ligne de commande dans un xterm. Sur Windows par contre cela marche bien.

Le controleur généré pour lister l’ensemble de mes offres d’emplois est simple :

package org.letouilleur.testroo.web;

import org.springframework.roo.addon.web.mvc.controller.RooWebScaffold;
import org.letouilleur.testroo.domain.JobPost;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.stereotype.Controller;

@RooWebScaffold(path = "jobposts", formBackingObject = JobPost.class)
@RequestMapping("/jobposts")
@Controller
public class JobPostController {

}

J’ai essayé d’ajouter un field sur une Entité sans relancer Tomcat, mais cela ne marche pas. Par rapport à Play! Framework vous devez relancer votre serveur. J’ai essayé plusieurs fois, mais je pense que la partie Aspect redemande une compilation. Nous parlons d’annotations avec une rétention au niveau source, cela semble logique.

Des modules ? des plugins ?

Spring Roo permet de mettre en place des aspects comme la sécurité, l’indexation avec SolarR des entités, ou même l’envoi d’un email. Il est aussi possible de développer ses propres outils par exemple.

L’intégration avec Google GWT et Google App Engine est particulièrement poussée. De même que l’outil Cloud Foundry, qui appartient à SpringSource et qui permet de gérer facilement la plate-forme de cloud d’Amazon.

Ce que j’ai aimé

Le contrat est rempli : en quelques minutes vous générez une application web sur un socle Spring, avec une approche très Domain Driven Design qui me plaît beaucoup. Bye bye DAO et Service, c’est une approche plus Web que j’aime bien. La mise en place d’un projet complet avec Maven est bien pensée. Le fait que ce soit du Java est un plus par rapport à Grails pour ceux qui ne connaissent pas encore Groovy.

Dans le cadre de la réalisation d’une application Web, c’est un choix à regarder. Je n’ai pas creusé ensuite l’implémentation dans la partie Controller. L’Add-on Web MVC de Spring Roo génère l’ensemble des méthodes type CRUD. Par contre vous ne les voyez pas dans le code de votre controleur. Ce sont des Aspects qui sont ajoutés ensuite dans la classe finale.

Spring Roo et Play! Framework font tous les deux de l’enrichissement de vos classes. Roo utilise des Aspects, Play! utilise le compilateur incrémental JDT d’Eclipse (pas l’IDE). L’avantage de Play! est qu’il déclare des méthodes dans les classes comme JPASupport ou Model, que vous étendez ensuite dans votre entité. Ceci permet d’avoir de la complétion lorsque vous codez. Votre IDE connaît les méthodes et vous ne perdez pas le typage fort. Ces méthodes sont implémentées lors de la compilation, qui est fait par Play! au lieu d’être fait via Maven ou votre IDE.

La liste des Add-On est déjà bien avancée, et nous n’en sommes qu’à la version Spring Roo 1.0.0.M3. Il y a une bonne communauté déjà semble-t-il.

Un point fort c’est que Roo ne vous locke pas, puisque l’essentiel de l’outil est constitué d’annotations, d’aspect et d’un outil qui surveille votre arborescence de code.

Ce que j’ai moins aimé

Le support dans IDEA IntelliJ est pas top. Lorsque vous codez des pages JSF par exemple, pas de complétion possible avec les actions de votre controleur lorsque vous référencez votre bean. Ce n’est pas la fin du monde, mais on perd du temps. Le support dans l’outil SpringSource STS est bien meilleur. Je vous conseille de le tester et de laisser tomber IDEA IntelliJ ou NetBeans avec Spring Roo pour l’instant.
A priori le support des Aspects dans IDEA 9 avec la version 1.0.0.M3 semble fonctionner. Cela vous permet par exemple d’avoir la complétion des getters/setters sur votre entité au sein du code de votre Controller. Mes derniers essais avec IDEA 9.0.3 professional edition n’était pas concluant, car cela ne marchait pas. Je testerai à nouveau, car sans cette fonctionnalité, et bien Spring Roo perd de son intérêt.

Ne vous amusez pas à changer la structure des packages, ou à essayer de déplacer vos entités dans un autre projet Maven. Comme Grails et comme Play! Framework, il faut accepter un certain cadre pour que l’outil fonctionne. Donc si vous êtes un ayatollah de l’architecture, ben ce sera pas trop votre ami. C’est le même souci avec tous ces outils comme Play! ou Grails.

J’ai un mauvais souvenir de Grails et de la partie CRUD, où finalement j’avais terminé par faire mes pages, mes actions et mes tags. J’ai un mauvais souvenir du module CRUD de Play! qui ne couvre pas mes besoins, et qui n’est pas fait pour être surchargé (encore moins que Grails).
Donc forcément, je n’ai pas mis le nez dans les JSPx, mais je sens que pour faire une vraie application la partie CRUD ira aussi à la benne. On s’en sert pour montrer les bonnes pratiques, mais pour faire une vraie application ? Je me base sur l’exemple de la Pizzeria de la doc de Roo pour appuyer cet argument : j’y crois pas sur une application réelle sur le Web (…genre un jobboard où tu as bossé 5 mois dessus tu vois…)

Ce que je n’ai pas testé

J’ai reposé le crayon après avoir généré mon squelette de code, et je n’ai pas tellement testé la construction d’un vrai projet (je vous le dis honnêtement). J’aime bien essayer de gérer les relations OneToMany/OneToOne/ManyToMany et voir comment s’en sort le framework. Grails avec GORM est particulièrement bon, cette partie est mature. Chez Play! Framework c’est JPA, donc le framework ne fait rien de plus que ce que vous feriez par ailleurs. Ce sera à vous de coder cette partie. Côté Spring Roo, vous pouvez déclarer des relations entre vos entités, et Roo vous aide à les mettre en place. A voir ensuite du côté de la vue comment cela fonctionne.

Je n’ai pas testé la partie tests unitaires et tests d’intégrations avec Selenium, qui me semble bien fait. Cela fait bizarre de faire tester par Roo du code qu’il a lui-même écrit…

Enfin à priori l’outil ne générera pas de code avec des beans Java EE 6 ou CDI. Par contre la partie JPA fonctionne très bien.

Conclusion

Spring Roo est un outil de productivité, qui a le mérite de proposer de bonnes pratiques, et un socle purement basé sur Spring. Pour écrire une application avec un noyau Spring franchement essayez-le. Simple à mettre en place, l’essai ne vous coûte pas cher.

Dans les demandes des utilisateurs, une demande ouverte en 2009 et qui est en cours de traitement porte sur la reprise des JSP modifiées par Spring Roo (voir ROO-8). C’est quelque chose qui est bien traité dans Grails, et je trouve que Roo s’aventure sur un terrain où il y a déjà 2 ans de travail. Grails est vraiment une belle machine, et il tourne bien.

Prenez le temps de tester et de vous faire votre propre opinion, c’est un bon outil.

Références
– Lisez la documentation de référence, la philosophie de l’outil est bien expliqué.
– Le site d’AspectJ
– Why Spring Roo is not my thing ? Bon article sur le blog GridShore
– Spring Roo sucks ! : les arguments sont un peu léger, et il y a un peu de mauvaise foi.
– Spring Introduction in 10mn sur le site d’InfoQ
– Spring Roo : the answer to rapide development ? sur DZone

Articles similaires:

Evénement Spring le 13 novembre 2008 Revue du livre Spring par l'exemple de Gary Mak Introduction à Spring Integration Spring : keep-it under control