Compte-rendu du second “Java Barcamp” à Paris

Mardi 16 décembre se tenait à Paris le second “Java Barcamp”, dont le principe est de laisser les participants décider du contenu des séances. Voici le compte-rendu de celles auxquelles nous avons pu assister.

Génération de code

Le débat a d’abord porté sur les use-cases pour la génération de code. Pour certains, le principal intérêt est d’abaisser la barrière technologique initiale pour les développeurs juniors, et de faciliter la reconversion de développeurs “legacy”, en générant tout le socle technique. Pour d’autres, la génération de code est surtout un moyen de factoriser des bonnes pratiques et d’améliorer la productivité et la satisfaction des développeurs en automatisant les tâches répétitives et/ou peu valorisantes (ex: générer le struts-config.xml).
La conversation a ensuite porté sur les outils associés. Si ceux-ci sont relativement performants sur les couches basses (génération de DAO), la génération d’interfaces graphiques reste toujours problématique et généralement plus coûteuse que du développement spécifique. Toutefois, les outils évoluent, et savent maintenant prendre en compte les modifications manuelles lors des phases de re-génération. Mais il est parfois plus efficace de créer son propre générateur. Dans ce cas, la règle du 80/20 s’impose : inutile de chercher à gérer tous les cas possibles du premier coup. Le générateur doit au contraire rester simple et facilement adaptable, particulièrement dans le cadre des méthodologies agiles où les spécifications peuvent changer à chaque itération.

Usine logicielle et intégration continue

La premier sujet abordé a été “Maven au delà du poste de développement”. Un sujet délicat, qui revient très souvent. Dans la plupart des cas, le rôle de Maven doit s’arrêter à la phase de packaging des produits; des scripts existants de types ksh ou shell seront utilisés pour le déploiement.
L’autre point abordé a été l’utilisation de Maven dans les IDE. Pour Eclipse, l’utilisation de Maven est facilitée par l’intégration de nombreux plugins existants, qui sont aujourd’hui plutôt mûrs. Pour IDEA IntelliJ, son intégration très avancée est presque transparente pour l’utilisateur.
Il a été discuté ensuite de l’automatisation des tests d’IHM avec Selenium et de l’intégration aisée avec Maven. Enfin, une question ouverte a été posée sur le choix de Maven pour des projets non JEE sortant des conventions, avec la découverte des nouveaux outils de build tels que Gant et Gradle.
Le second sujet portait sur les serveurs d’intégration continue. Il s’agit d’un sujet très en vogue en ce moment. En termes de choix d’outils, toutes les personnes dans la salle étaient unanimes sur le fait qu’Hudson était le serveur d’intégration continue incontournable en ce moment. La grande fréquence de livraison du produit et l’intégration de différents plugins a été pour finir abordée. En conclusion, Hudson est un concurrent de taille, comparé à son challenger TeamCity.

ESB : Spring Intégration & Mule

L’audience comportant une forte proportion de novices, la séance a débuté par un rappel du principe des ESBs. Un ESB est un peu l’équivalent moderne de l’opératrice téléphonique : il permet de mettre en relation des ressources d’entreprise “parlant” des langages différents (ftp, mail, fichier, jms…) , c’est un facilitateur de communication.
Spring Intégration n’est pas officiellement appelé ESB à cause de la connotation de lourdeur que ce sigle véhicule. Revendiquant au contraire une grande légèreté, il est prévu pour fonctionner sur de petits serveurs, et même être lancé au sein de simples tests unitaires. Il dispose pourtant de tous les principaux connecteurs, et devrait même être compatible avec ceux du projet Apache Camel. Spring oblige, la configuration peut être réalisée XML ou grâce à des annotations. Bien que possédant déjà quelques “success stories”, Spring Intégration peine encore à percer en France.
La conversation a ensuite porté sur Mule, la référence actuelle. Défini comme une “multiprise inter-applicative”, il se base sur l’architecture SEDA (Staged Event-Driven Architecture), dont le principe est de disposer d’unités de traitement autonomes reliées par des queues de messages. Egalement très simple à mettre en place, il offre la particularité de pouvoir définir quelles opérations sont synchrones ou non, et de gérer les transactions distribuées entre plusieurs types de connecteurs.
La séance s’est terminée sur une évocation du portfolio SpringSource, notamment Spring Batch et Spring DM Server.