Créer le modèle objet avec Hibernate, et générer le schémas automatiquement est une pratique courante. Mais lorsqu’on souhaite garder la main sur le schéma généré, en production par exemple ? Voici comment résoudre ce problème en insérant une étape de génération du schémas au sein d’un build piloté par Maven2.
Tout le monde s’accorde sur l’utilité des tests de non régression automatisés, d’ailleurs les outils disponibles dans la sphère Java sont légion : jUnit, dbunit, jmock …
Mais de là à les voir mis en oeuvre systématiquement sur les projets il y a un pas ; l’un des reproches revenant le plus est : « les tests sont trop coûteux à écrire ».
(Lire la suite…)
Grails est un socle OpenSource qui propose un cadre standardisé et simplifié pour le développement d’applications compatibles JEE. Reposant sur des frameworks reconnus comme Hibernate, Spring, Groovy, Grails améliore sans commune mesure la productivité des développements sans demander un investissement lourd d’adaptation. Grails est à lui seul un environnement intégré qui permet de construire et déployer très rapidement une application.
Cependant, convaincus chez OCTO Technology par la valeur de Maven pour industrialiser les développements d’applications et pour faciliter le travail collaboratif en particulier dans les entreprises, nous avons rapidement trouvé des manques dans Grails dès que l’application grossissait au fur et à mesure des itérations. Par exemple, la possibilité d’utiliser facilement les librairies fournies par d’autres équipes projets. Là où Maven permet de le faire à l’aide d’une simple description en gérant les dépendances transitives, avec Grails nous retournons des années en arrière avec la gestion manuelle des librairies dans un repertoire lib du projet sauvegardé dans le gestionnaire de versions (avec tous les problèmes de maintenance que cela peut engendrer à long terme).
Comme nous n’étions pas les seuls à faire ce constat, nous avons relevé nos manches pour faire le nécessaire afin de permettre de construire des applications Grails avec Maven 2…
OCTO sponsorise et participe à la première conférence internationale Grails eXchange qui aura lieu à Londres du 17 au 19 octobre 2007.
Les consultants OCTO Gilles Laborderie, Ismael Héry, Fabrice Robini, Arnaud Héritier et Guillaume Laforge (membre actif des communautés Groovy et grails) y présenteront les 3 sessions et la keynote suivantes:
(Lire la suite…)
En mai a lieu la plus grande conférence Java de la planète, organisée par Sun, à San Francisco. Après avoir soumis un papier pour présenter Groovy, ma proposition a été acceptée, et j’ai également été invité chez Google pour une autre présentation par Dick Wall, l’un des créateurs du fameux podcast JavaPosse.
Tout d’abord il faut préciser une petite chose : le périmètre fonctionnel des deux frameworks est totalement différent :
Spring est un framework qui entend couvrir l’ensemble des problématiques allant de la simple application CRUD à l’application d’entreprise :
Google Guice couvre principalement l’injection de dépendances (également l’AOP, mais cela reste assez basique). C’est donc sur l’IoC qu’il est opportun d’effectuer une comparaison avec Spring.
Google Guice s’appuie principalement sur les fonctionnalités de JAVA 5, et plus précisément sur les annotations pour la configuration.
Les principaux reproches fait à Spring concernent la configuration, principalement sur les fichiers XML qui deviennent complexes et difficiles à maintenir dès lors que l’application devient conséquente. Même avec la version 2, sortie tout récemment, Spring n’a pas véritablement simplifié cette configuration qui reste basée sur du XML.
Mars 2006. La comète Grails fait son entrée dans la galaxie Java en sortant sa première version publique. Inspiré par le succès du framework Ruby on Rails, Grails propose alors d’en adapter la recette à la sauce Java. Sa promesse ? Fournir une solution simple, rapide et élégante pour développer des applications Web J2EE pour l’entreprise.
Mars 2007. A quelques jours du premier anniversaire du framework, force est de constater que l’engouement autour de Grails reste intact. Chez OCTO comme chez nos clients, de premières références significatives voient le jour en production. On commence à y croire : Avec Grails, ca va vite.
Grails venant enrichir une panoplie de solutions déjà à notre disposition pour nos développements Web, des questions se posent : Choisir Grails, pourquoi pas, mais dans quels cas ? Est-il adapté aux contraintes d’un SI d’entreprise ?
Dans quels contextes et de quelle manière Grails peut-il faire la différence ?
Je suis récemment tombé sur le nouveau framework d’IoC/DI de Bob Lee: Google Guice. J’ai plutôt tendance à utiliser Spring pour ce genre de tâche, entre autre parce que Spring va beaucoup plus loin que simplement l’IoC/DI, mais je me suis dit que j’allais laissé sa chance à Guice, et que ça allait me permettre de jouer avec le support des annotations dans Groovy. Donc j’ai téléchargé Guice, et j’ai leu la documentation. Par ailleurs, j’ai pris un « snapshot » de Groovy 1.1 qui supporte les annotations Java 5. Puis avec guice-1.0.jar et aopalliance.jar dans mon classpath et la dernière version de Groovy installée, j’étais prêt à expérimenter !
(Lire la suite…)
