Tag :Maven3

Soirée Gradle/Maven 3 au Lyon Jug (23/11)… deuxième partie!

Comme nous vous l’avions déjà mentionné en début de semaine, les speakers du prochain Lyon JUG, le 23 novembre prochain, seront Grégory Boissinot et Arnaud Héritier. Ils présenteront respectivement Gradle et Maven 3. Pour vous donner envie d’assister à la session, nous avions posé quelques questions à Arnaud sur Maven 3, aujourd’hui nous nous tournons vers Grégory, expert de l’intégration continue chez Zenika et évangéliste Gradle…

Agnès : Alors, en quelques mots, comment peut-on définir Gradle? Pourquoi dit-on qu’il s’agit d’un système de build de “troisième génération”? Maven est-il relégué à la seconde génération?

Grégory: Gradle est un système de build écrit en Java et Groovy pour la construction (le build) des projets Java, JEE, Groovy, OSGI et Scala. Gradle est dit système de troisième génération car d’une part il arrive après l’ère des systèmes de première et deuxième génération autour de ANT /Ivy et Maven. Il a été bâti en gardant les meilleures fonctionnalités sans les inconvénients des systèmes précédents. Et d’autre part, Gradle offre une nouvelle approche en étant spécialement conçu pour adresser les besoins de l’entreprise. A l’inverse Maven prévaut un ensemble de standards et de conventions que les applications doivent adopter pour utiliser Maven. Malheureusement dans la réalité, les besoins des projets sont très spécifiques et Maven n’offre pas une aussi très grande richesse de personnalisation de son build que Gradle. De plus, il existe de très nombreux projets existants, conçus avant Maven, et qui ne peuvent pas migrer à Maven de par leurs spécificités. Afin de ne pas laisser pour compte tous ces projets, Gradle expose directement une API publique lui permettant d’offrir un grand niveau de personnalisation. Et comme on ne peut pas anticiper tous les besoins, l’API de Gradle est très extensible afin de permettre à l’intégrateur la mise en place en place de son propre modèle de build.
Par exemple, Gradle propose un système qui permet à l’utilisateur final de ne pas exécuter certaines parties de son build (techniquement par la désactivation de taches, possible nativement par l’affectation de la propriété enabled à false), sans une connaissance approfondie de l’outil et donc sans avoir besoin d’un expert du build. En comparaison, avec Maven, il est nécessaire d’ajouter des éléments de configurations dans les plugins Maven. Et avec Ant, cela nécessite une prise en compte préalable à travers des propriétés. Gradle s’amène également avec de nombreux concepts comme un outil de gui ou son wrapper pour faciliter l’installation de Gradle sans besoin d’administration.
Et c’est tous ces éléments qui font de Gradle un système de troisième génération.
Depuis quelques mois la nouvelle mouture de Maven, Maven 3 est sortie. Malgré une réécriture complète du noyau de l’outil pour gagner en performance et un peu en extensibilité, celui-ci est encore trop fortement lié aux concepts de Maven 2 en proposant une structure rigide au lieu d’un modèle (via une API) extensible afin d’adresser l’ensemble des spécificités des projets. C’est pourquoi, à l’inverse de Maven, ce n’est pas au projet de s’adapter au système de build mais c’est le système de build, Gradle, qui s’adapte à vos besoins, à vos spécificités, le tout dans une approche déclarative et concise pour faciliter la maintenance sur le long terme.

Agnès : Au sein d’une entreprise, puis-je faire cohabiter facilement Maven et Gradle? Si je dispose d’un repository d’entreprise stockant tous les artefacts de l’entreprise, un projet géré par Gradle peut-il continuer à récupérer ses dépendances au sein de ce repository?

Grégory: Les fonctionnalités de Gradle en font un véritable système de build offrant une alternative complète et mature vis-à-vis des systèmes de build actuels comme Maven.
Néanmoins devant la forte utilisation de Maven et de son écosystème sur le marché, Gradle a été conçu pour s’insérer dans une infrastructure existante à base de Ant, Ivy et Maven.
Et dans ce mode d’utilisation, Gradle offre la flexibilité et la souplesse manquantes dans votre outillage actuel.
Par rapport à la question, prenons l’exemple de l’insertion dans une infrastructure Maven.
Avec Maven, vous avez deux niveaux d’infrastructure. Le premier niveau concerne un projet Maven constitué d’une arborescence standardisée et d’un ou plusieurs descripteurs de build Maven. Le second niveau d’infrastructure concerne le repository Maven. Il s’agit d’un dépôt d’artefacts ayant pour vocation de regrouper toutes les librairies Maven. Ces librairies Maven s’accompagnent de métadonnées permettant une identification unique des artefacts.

Concernant le premier niveau, Gradle utilise par défaut les mêmes conventions que Maven, c’est-à-dire un répertoire dédié pour le code source de production, les ressources de production, le code source des tests et ainsi de suite.
Pour le second point, il n’y a pas non plus de problèmes car l’outil Gradle délègue sa gestion de dépendance au système Ivy. Celui-ci est un gestionnaire de dépendances très évolué capable de requêter un dépôt Maven. De plus, Gradle utilise les Maven Ant Task (un bout de Maven) pour déployer ses artefacts dans un repository Maven avec la métadonnée Maven associée. Sur ce dernier point, l’utilisation de Maven pour le déploiement garantit à Gradle une génération des artefacts Maven 100% compatible avec un écosystème existant comme un repository Manager Maven (tel que Sonatype Nexus, Jfrog Artifactory, Apache Archiva) capable d’administrer uniquement des repositories Maven.
Ainsi, Gradle est capable de lire et d’écrire dans un repository Maven nativement, sans configuration particulière.
Cette fonctionnalité est très intéressante car elle permet de garder un repository Maven commun à l’organisation ou à l’entreprise avec des projets ou des applications qui utilisent en fonction du besoin soit Maven soit Gradle.

Agnès : Aller, c’est décidé, je veux essayer d’utiliser Gradle… Bon, comment attaquer? Si j’utilise Maven sur un projet existant, est-ce compliqué de migrer de Maven à Gradle? Je démarre from scratch ou existe-t’il un équivalent au plugin maven archetype qui permet de générer un squelette d’application pour démarrer? Et puis-je facilement intégrer mon projet dans un processus d’intégration continue, en l’occurrence de préférence avec un des outils déjà en place dans mon entreprise, par exemple Hudson?

Grégory: Il n’existe pas malheureusement pas pour le moment d’archetype (template de projet) Gradle. Je l’avais proposé à son créateur Hans Dockter il y a maintenant presque 2 ans, mais par manque de temps, cela ne s’est pas fait. Cette fonctionnalité sera certainement fournit prochainement.
Oui, Gradle s’intègre parfaitement avec vos serveurs d’intégrations comme Hudson. Concernant ce dernier, il existe un plugin Hudson pour ordonnancer des chaines de build Gradle. Ce plugin permet d’ajouter des étapes Gradle à vos processus d’intégration. Et il est également doté d’une fonctionnalité permettant d’installer Gradle et d’utiliser cette instance si vous essayez d’exécuter Gradle sur un nœud de votre serveur d’intégration continue dans le cas où celui-ci n’est pas préalablement installé et configuré. Cette dernière fonctionnalité est particulièrement intéressante car elle assure une parfaite portabilité de vos builds vis-à-vis de vos machines sur lesquelles s’exécutent ces instances de processus d’intégration.

Agnès : Gradle s’intègre t’il bien à la plupart des IDE?

Grégory: L’intégration de Gradle dans les IDE est malheureusement la partie la moins développée de Gradle.
L’IDE IntelliJ de la société JetBrains a commencé à proposer un support en fournissant un début de la reconnaissance de la syntaxe Gradle et la possibilité d’exécuter son script Gradle depuis l’IDE. Néanmoins, le support de Gradle est encore loin de celui de Maven en n’offrant pas la possibilité par exemple de mettre à jour son classpath dynamiquement lorsqu’on change les dépendances de son projet.
Et concernant les deux autres principaux IDE que sont Eclipse et NetBeans, il n’y a pas de support de Gradle pour le moment.
Néanmoins, même si les IDE ne proposent pas encore un support correct de Gradle, Gradle lui-même fournit des plugins permettant de générer les métadonnées pour le support d’un projet Gradle dans l’IDE comme par exemple un plugin eclipse de Gradle générant les fichiers .classpath, .project et le répertoire .settings.
Similaire, au plugin maven-eclipse-plugin pour la génération des métadonnées Eclipse dans Maven, cela permet à chaque utilisateur d’importer correctement son projet dans Eclipse et de constituer correctement son classpath de compilation et d’exécution.
A chaque modification de son descripteur de build, il est nécessaire d’exécuter de nouveau la commande de génération des métadonnées de l’IDE.
Actuellement, les plugins IDE de Gradle sont maintenus et donc intègrent les spécificités des dernières versions de Eclipse et IntelliJ (point positif pour Gradle car ce n’est plus le cas de son petit-frère coté Maven).
En revanche, je ne sais pas pour combien de temps ces plugins Gradle pour les IDE seront maintenus et pourront intégrer toutes les fonctionnalités des dernières versions des IDE, tout en étant compatibles avec les anciennes versions.
C’est pourquoi, à terme, le support coté IDE (à travers des plugins de l’IDE) de l’outil de build Gradle est la meilleure approche et fournira une intégration plus native.
Malgré tout, nous pouvons nous poser la question de l’urgence d’un tel support dans les IDE. En effet, Gradle, comme tous les outils de build est un outil de construction des applications, utilisé au moment de l’étape d’intégration de son projet. Ainsi, pourquoi un outil conçu pour les intégrateurs devrait-il aussi adresser les développeurs et leurs outils de travail quotidien qui est l’IDE ?
De mon point de vue, sur des grosses équipes de développements et suivant un modèle de développement JEE, je recommanderais de ne pas déployer l’outil de build sur chaque poste de développement mais uniquement sur les postes des intégrateurs. Les développeurs utilisent alors uniquement les fonctionnalités très avancées et entièrement suffisantes de leur IDE pour l’implémentation de l’application et les éventuelles taches de micro-déploiement.

Agnès : Hibernate a migré de Maven à Gradle. Un des lead programmer d’Hibernate, Steve Ebersole, explique notamment que le processus de release avec Maven était particulièrement lourd (je le rejoins sur ce point!), comment Gadle assouplit les releases de version?

Grégory: Oui, dans la prochaine version de Hibernate, c’est à dire Hibernate 4, c’est l’outil de build Gradle qui sera utilisé pour construire les différentes librairies. Cela va permettre à l’équipe Hibernate de d’offrir la souplesse nécessaire et d’épouser au plus près leurs besoins.
L’utilisation de Gradle sur le projet Hibernate va apporter une très grande notoriété à Gradle et permettre espérons-le d’accélérer la mise à disposition des nouvelles fonctionnalités prévues.
En ce qui concerne le processus de livraison de Maven (la release), il s’agit en effet souvent d’un processus souvent lourd et laborieux.
De manière simplifiée, le principe est de prendre en en entrée un projet Maven qualifié en phase de développement (à travers l’utilisation du mot clé SNAPSHOT dans la valeur de sa version).
Puis, Maven applique un ensemble de contraintes et lance la phase de construction du produit qui sera la version livrée. Le processus de release s’accompagne d’un dialogue étroit avec le système de gestion de configuration logicielle en place sous lequel est géré le projet Maven. Par exemple, dans le cadre de Subversion, Maven pose des tags, met à jour les descripteurs Maven contenant les versions livrées et la valeur de la prochaine version.
Ce principe souffre de nombreuses contraintes.
Premièrement, ce processus est figé et suit un cycle de livraison précis, peu modifiable et ne correspondant pas nécessairement au processus de livraison imposé par l’entreprise.
Par exemple, pourquoi reconstruire un produit qui a déjà été validé par des équipes de test. En effet, au moment de l’exécution du processus de livraison, l’ensemble des tests unitaires et des tests d’intégration sont exécutés. Mais cela n’est pas suffisant et il manque tous les autres tests. Malgré l’extrême prudence dans la traçabilité avec en particulier l’outil SCM, on peut se demander pourquoi reconstruire ?
Un processus classique consiste généralement à produire un ensemble de versions (généralement suffixé d’un timestamp) de son application, puis ces différents binaires sont envoyés à des équipes de tests qui qualifient le produit selon différents critères préalablement établis et c’est ensuite eux qui décident quelle version sera envoyée en production. Mais dans la chaine de livraison, il n’y aura à aucun moment une reconstruction du logiciel car on ne peut pas garantir que cela soit le même binaire et cette reconstruction semble injustifiée, pas nécessaire. De nouveau, en imposant un processus établi à l’avance, Maven n’adresse pas des milliers de projets industriels.
Et d’autre part, ce mécanisme de livraison de Maven est trop lié, fortement couplé à l’outil SCM. Dans le cadre de Subversion, il n’y a pas beaucoup de problèmes car il s’agit uniquement d’un outil de gestion de révisions. L’outil ne fournit aucun processus logiciel et ainsi, il est facilement possible d’interagir avec Maven qui pilote la version et constitue les tags. Mais pour d’autres outils de gestion de configuration logicielle comme Clearcase, c’est l’outil lui-même qui dicte les éléments livrés et la version du produit. Ainsi, ce n’est pas Maven qui détermine la version et produit les éléments de traçabilités dans la gestion de configuration logicielle, mais à l’inverse, les éléments de gestion de configuration logicielle sont produits à l’extérieur et fournis en entrée aux outils.
Maven impose donc un processus de livraison rigide qui rentre souvent en conflit avec les outils en place au niveau de l’équipe.
Par rapport à ces problèmes, Gradle répond mieux aux besoins des projets en n’imposant pas systématiquement une version, celle-ci est optionnelle. De plus, Gradle n’impose pas de processus de livraison particulier. Gradle va permettre (grâce à son API extensible) de définir un modèle (une dsl) permettant l’implémentation exacte d’un modèle livraison établi par l’équipe.

Merci à Anne-Laure Rigaudon pour son aide sur la préparation de cet interview.
Inscriptions et informations pratiques sur la soirée sur la page officielle du Lyon JUG

Soirée Gradle/Maven 3 au Lyon Jug (23/11)

Le prochain Lyon JUG va ouvrir son ring, le 23 novembre prochain, à Grégory Boissinot, dans le rôle du défenseur de Gradle et à Arnaud Héritier pour présenter Maven 3. Pour vous donner envie d’assister au combat, petit aparté dans les coulisses avec chacun d’eux. On commence par Arnaud Héritier, membre des communautés Apache Maven et Codehaus Mojo et auteur du livre Apache Maven, avec quelques questions autour de Maven 3…

maven

Agnès : Avant de rentrer dans le détail, quelles sont les grandes évolutions de Maven 3 vis-à-vis des précédentes versions 2.X?

Arnaud : Si on se limite à Maven 3.0 les utilisateurs vont être déçus car en surface il n’y a pas grand chose. La grosse nouveauté de la version 3.0 reste le mode multi-threadé qui permet d’exécuter la construction des modules en parallèle en fonction de leurs contraintes d’ordonnancement (pensez à mettre à jour vos plugins avant de tester cette fonctionnalité afin de ne pas avoir de bug ou de comportement étrange).
Dans les petits plus on retrouve un meilleur rapport sur les erreurs dans les descripteurs de projets et lors de l’échec du build. La gestion des dépendances et la résolution des conflits de versions et de la transitivité ont aussi été revues afin d’apporter une meilleure stabilité.
Enfin les performances ont été légèrement améliorées (tout dépend ensuite du projet lui même et des plugins utilisés).
Si l’utilisateur n’y voit donc pas beaucoup de changement c’est que les grosses évolutions de la version 3.0 sont ailleurs : sous le capot. Le moteur a été en grande partie réécrit pour permettre une bonne évolutivité à l’avenir que ce soit au niveau de ce noyau, de la gestion des descripteurs ou des plugins.
Cette version 3.0 n’est donc pas révolutionnaire pour l’utilisateur final en lui-même mais ouvre de nombreuses possibilités dans un avenir proche.
Et la chose importante à noter est la conservation de la compatibilité avec les projets Maven 2 à 99,999….%. L’équipe a fait de gros efforts la dessus afin de permettre à la communauté de migrer le plus rapidement possible sur cette nouvelle version et de bénéficier des grandes nouveautés qui se préparent mais qui ne verront le jour que pour Maven 3.x.

Agnès : Avec Maven 2, le partage de configuration ne pouvait se faire que par héritage de pom, pouvez-vous nous décrire l’intérêt des “POM mixins” de Maven 3 vis-à-vis de ce point?

Arnaud : Effectivement aujourd’hui l’une des grosses limitations des descripteurs actuels est le fait qu’ils ne permettent d’avoir qu’un héritage simple.
De ce fait lorsque l’on est dans une entreprise (ou dans une organisation qui gère plusieurs projets) si l’on veut pouvoir capitaliser dans la prédéfinition de la configuration des projets on ne peut envisager qu’un mécanisme à base d’un parent unique (avec potentiellement une sous-hiérarchie) qui a le gros désavantage de ne pas être modulaire.
On en vient à mélanger dans ce dernier des choux (informations sur l’environnement de build, repositories ..) et des carottes (paramétrage des projets et plugins) et la maintenance de ce dernier devient délicate (il ne faut pas le faire trop souvent pour éviter aux projets de décrocher et de rester dans une version préhistorique et il ne faut pas en faire trop rarement non plus pour intégrer les mises à jour utiles par les projets).
L’autre problème est que cet héritage unique ne permet pas de créer des descripteurs parents par typologie de module. Pour suivre les conventions Maven et bénéficier facilement de tout son outillage comme le plugin release il est nécessaire que le module hérite du parent qui est au dessus de lui dans l’arborescence des modules. De ce fait si dans mon organisation je veux préconiser des paramétrages pour les modules de type JAR via un premier parent et d’autres paramétrages pour les WAR via un autre parent c’est aujourd’hui impossible car tous les modules d’un projet doivent hériter directement ou indirectement du parent du projet en question (cela pourrait être aussi un découpage fonctionnel plutôt que technique).
Si nous étions en langage objet le contournement le plus répandu pour pouvoir hériter du comportement de deux classes sans le faire par héritage est d’utiliser la délégation. C’est donc ce que l’on va proposer dans Maven (3.1 pour l’instant dans la roadmap de Jason Van Zyl – fondateur du projet), un mécanisme de mixins qui va permettre de réinjecter des morceaux de POMs dans un POM donné. Ainsi si je veux customiser la configuration du plugin XXX pour tous mes projets, je vais déployer ce morceau de descripteur dans mon repository et je vais dire aux projets de l’utiliser. Ainsi ces derniers pourront réutiliser à la fois la configuration d’un POM décrivant l’infrastructure physique, un autre lié au type technique du module et un troisième en fonction de son aspect métier. Tout cela permettra de réutiliser la configuration en continuant de capitaliser dessus (C’est un des aspects important de Maven que de permettre de capitaliser les bonnes pratiques).

Agnès : La gestion des dépendances Maven 2 pose quelques soucis, notamment la gestion des dépendances transitives. Nous sommes parfois amener à tuner les dépendances et leurs exclusions pour éviter les conflits de versions plutôt que de simplement lister la liste complète des dépendances. Maven 3 propose t’il une stratégie différente de gestion des dépendances ?

Arnaud : Le mécanisme des dépendances à été revu pour gérer un peu mieux la résolution des conflits et la transitivité ce qui devrait quelque peu améliorer les choses. Il est aussi plus ouvert ce qui permettra de faire cohabiter plus facilement des versions à la maven avec des versions a à la OSGi par exemple.
Cependant rien n’est parfait et beaucoup de problèmes reprochés aux dépendances Maven ne viennent pas du produit lui-même (qui n’est pas magicien et ne peut avoir la science infuse) mais des descripteurs déployés sur les repositories par les projets open-source ou d’entreprises. Combien de fois ne voit-on pas de séparation des APIs et des implémentations dans des modules distincts afin de ne pas forcer l’utilisateur du projet XXX à récupérer l’ensemble des dépendances de l’implémentation alors que ce dernier n’en a peut être pas besoin ? Combien de fois voit-on des scopes mal positionnés, les gens ayant du mal à comprendre le sens et l’utilisation de chacun (faute à nous de mal l’expliquer ou documenter je peux l’admettre).
Sur tout ces points nous n’avons que peu de marge de manœuvre si ce n’est évangéliser et mieux documenter encore et toujours.
Du côté outils, les versions 3.x vont enfin nous permettre de faire évoluer le modèle de descripteur de projet sur la forme (ceux qui détestent le XML pourront l’écrire dans un autre langage, cf http://polyglot.sonatype.org/ fournit par Sonatype) et sur le fond (nous allons pouvoir rajouter de nouveaux éléments dans le modèle). Ainsi nous allons rajouter dès que possible la capacité d’exclure globalement des dépendances pour tout le projet/module. Cela ne réglera certes pas le problème de base qui est la mauvaise qualité des descripteurs existant mais cela devrait grandement faciliter la vie de leurs utilisateurs qui auront moins à pâtir de ces problèmes.

Agnès : La gestion des plugins maven est toujours assez compliquée… (plugins disponibles en version beta, voir alpha!). Est-il prévu de modifier cette gestion des plugins (en distinguant les plugins en incubation des plugins stables par exemple)?

Arnaud : Il y a déjà eu des gros efforts ces derniers mois pour sortir des cycles interminables d’alpha/beta tous les plugins gérés directement par l’équipe Maven (cf http://maven.apache.org/plugins/index.html).
Des travaux sont en cours en ce moment sur le sujet pour justement faire du ménage sur ceux qui ne vivent plus (faute de besoin ou de ressources). Pour ceux que l’équipe ne saurait maintenir par elle même mais qui restent utiles, nous envisageons de les déporter dans des espaces où la communauté est plus ouverte comme mojo.codehaus.org ou github.
Il restera la question du référencement de tous les plugins existants. Pour l’instant ce sujet avance peu mais il y a tout de même beaucoup de travaux concernant la gestion du repository central et il serait envisageable que ce soit ce dernier qui puisse offrir aux utilisateurs un catalogue complet des plugins disponibles.

Agnès : Dernière question sur les axes stratégiques de Maven… Hormis le processus de build à proprement dit (compilation+TU+packaging), quel est le périmètre fonctionnel visé par Maven :

  • Couverture de code, JavaDoc, PMD, etc. devrait-il être de la responsabilité de Maven ou d’outils comme Sonar ?
  • Arnaud : Ce qui est assez paradoxal aujourd’hui c’est que ce qui a lancé Maven face à Ant il y a 10 ans c’était cette gestion intégrée de tout l’aspect qualitatif des développements. Aujourd’hui il est vrai que cet axe est en perte de vitesse car d’autres outils externes, plus puissants mais bien intégrés comme sonar le font très bien. A mon avis tout ce qui est reporting sur la qualité va doucement disparaitre au profit de Sonar qui contrairement au site web statique généré par Maven gère en plus l’historique. Par contre les plugins de gestion de la qualité continueront à évoluer (peut être en s’intégrant eux-mêmes nativement au serveur sonar) pour permettre de mettre des règles bloquantes au niveau de l’intégration continue (Non, Non, je ne veux pas de catch vide !!!). Cela ne veut par contre pas dire que l’aspect site documentaire de Maven va disparaitre car lui peut avoir un véritable intérêt.

  • Le déploiement automatisé (plugin Cargo, Tomcat, SQL, etc.) devrait-il être de la responsabilité de Maven?
  • Arnaud : Aujourd’hui le mouvement devops remet au gout du jour toute cette problématique de déploiement continue. Il y a de nombreux threads récemment à ce sujet (voir ici ou ici). Je ne suis pas certain que Maven doivent fournir tout l’outillage nécessaire car il s’agit d’un service spécifique. En général on va mettre cela en place sur un serveur dédié utilisant hudson ou un autre outil d’intégration continue. Ca n’est pas le développeur qui fera le déploiement en continu, cela pourrait donc être un service de ces serveurs.
    Du coté développeurs il a aussi besoin de déployer son application pour travailler dessus mais l’avenir devrait être à une intégration des IDE (même si ce n’est pas gagné aujourd’hui avec eclipse/WTP) et des outils comme JRebel. Il n’est pas possible de parler de productivité si les développeurs doivent à chaque changement d’une virgule lancer une commande maven dans un shell et attendre le redéploiement complet de l’application web. Maven doit être présent dans l’environnement de développement mais complètement intégré à l’IDE pour le rendre transparent.
    Pour moi cela n’est donc pas une priorité mais il y a cependant des personnes comme Sonatype ou MaestroDev qui travaillent sur ce sujet afin de fournir une intégration complète entre l’environnement de développement, le build, la distribution des binaires et leur déploiement (ex: Developer Onboarding, Proviso, Maestro3)

Merci à Gérald Quintana et Jean-Baptiste Nizet pour leurs conseils quant à la préparation de cet interview.
Inscriptions et informations pratiques sur la soirée sur la page officielle du Lyon JUG

JUG Summer Camp – Maven 3 au coeur de la Forge Logicielle


Maven 3 au coeur de la Forge Logicielle – Nicolas de Loof (présentation)
par Audrey Neveu

Forge logicielle, usine logicielle, industrialisation … autant de termes un peu rédhibitoires au premier abord qui recouvrent tous un même besoin : celui d’être pro ! Nicolas de Loof nous a donc fait faire un petit tour des outils nécessaires à toute usine de développement qui se respecte en nous présentant ses préférés.

La communication dans l’équipe

Tout d’abord prenons l’essence même de cette usine : l’équipe. Comme le déplore notre speaker, trop d’équipes sont constituées d’un nombre excédent de manager pour un trop petit nombre de développeur. Les premiers ne sachant pas toujours en quoi consiste réellement le travail du second, un projet peut rapidement tourner à la catastrophe.

Quelques conseils pour éviter ça :

  • favoriser la communication,
  • partager les connaissances,
  • éviter la spécialisation,
  • se renseigner sur ce que font les autres,
  • avoir une vision globale du projet.

Pour cela quelques outils intégrés peuvent venir à notre secours, l’important étant qu’ils s’intègrent de manière correcte entre eux. Le choix de Nicolas est la suite Jira pour la gestion du suivi des bugs, des incidents et de projets qu’ils proposent.

Agile ou fragile ?

Certains softs vous permettent de gérer votre backlog, vos sprints, etc … bref toute l’agilité de votre équipe en un clin d’œil. Néanmoins comme le rappelle notre speaker, le bon vieux post-it a un avantage indéniable : celui d’être constamment visible. En effet, un outil comme Greenhopper nécessite que votre équipe le consulte régulièrement, que chaque développeur fasse l’effort d’aller visualiser le tableau alors qu’un mur judicieusement choisi par vos soins et quelques post-its de couleur seront toujours bien visibles par l’ensemble de l’équipe.

Travailler à plusieurs

Un projet ça se construit à plusieurs, et pour cela il nous faut un outil pour partager notre code. A l’heure actuelle vous utilisez probablement svn, au moins dans votre vie professionnelle, et serez d’accord sur le fait que ce système de gestion des versions a de nombreux défauts, parmi lesquels la gestion des branches pour n’en citer qu’un. Notre speaker ayant succombé au charme du plus ravageur des SCM, c’est sans surprise Git qu’il aura retenu notamment parce que ce qu’il apprécie chez lui, c’est que votre façon de travailler localement n’impacte pas le reste du projet. Bien qu’encore récent, Nicolas prédit qu’il va révolutionner notre petit monde et pour peu que vous suiviez l’actualité de la communauté actuellement, vous conviendrez qu’il a probablement raison.

Outiller le projet

Le build

Qu’est ce que le build ? Rien de moins que la génération du binaire, l’initialisation de l’environnement, la création d’une base de données, la configuration de l’IDE, la gestion de l’encodage etc …

Le grand classique des outils de build est bien entendu maven : standard, portable, indépendant de l’environnement, Maven décrit les spécificités du projet plutôt que des commandes de construction.

Sa force réside dans les conventions qu’il a su imposer :

  • tous nos outils qui prennent en compte la convention de Maven fonctionnent dès qu’on les plugge,
  • n’importe quel développeur qui connaît Maven retrouvera rapidement ses marques, quelque soit le projet,
  • les mêmes commandes produisent les mêmes résultats,
  • il permet de tout faire sur son poste, sans un manuel de 50 pages pour comprendre les spécificités de gestion du build sur le projet.

Grâce à la gestion des dépendances, Maven a résolu le problème de la gestion des binaires : d’où vient ce jar, à quoi sert il, a-t-il été vérifié, comment diffuser nos propres binaires, quelle version est finale et quelle version est en snapshot ?

La meilleure solution pour profiter pleinement de la gestion des dépendances et des conflits est encore le repository manager qui va gérer l’indexation, la purge, la gestion des droits, etc … Le choix de Nicolas s’est porté sur Nexus version pro staging suite car il permet, entre autre de générer et déployer le livrable sans qu’il soit immédiatement accessible à tout le monde.

Tester

Que devez vous tester ? La réponse est simple : TOUT ! Aucun code ne devrait être livré sans avoir été testé, autrement dit : “All code is guilty until proven innocent”. Plusieurs méthodes s’offrent à vous pour réaliser vos tests, voyez plutôt :

  • le Test Driven Development ou TDD : on commence par écrire le test, on fait tourner les tests pour voir les problèmes rencontrés, on écrit le code nécessaire, on relance les tests et ainsi de suite. Aucun framework cité par Nicolas mais le grand classique du genre est, sans conteste, JUnit,
  • le Behaviour Driver Development ou BDD : une des pratiques de l’XP programming dont le but est de comprendre de manière précise le souhait du client au travers d’un langage compréhensible par un non développeur : les user stories deviennent directement les tests. Pour cette pratique le choix de Nicolas s’est porté sur Cucumber et JBehave,
  • les tests fonctionnels : ils visent à décrire le comportement que doit avoir l’application, de façon à ce que celui ci soit bien intégré par toute l’équipe, MOA comme développeur. L’outil le plus courant pour cette pratique et recommandé ici est Fitnesse.

Déployer l’application web

Pour piloter le lancement et le démarrage d’un serveur d’application, le speaker recommande Cargo, une application désormais un peu vieillissante ou encore Arquillian qui peut être vu comme son successeur. En effet, Arquillian permet de faire des tests d’application Java EE et ce, dans un conteneur embarqué ou déployé, avec possibilité de le démarrer à distance. On lui donne la description de l’archive à déployer avec des annotations et Arquillian se charge de tout : il déploie, lance les tests et donne un retour sur les résultats.

Test du comportement de l’application dans un navigateur

Afin de tester toute la partie fonctionnelle d’une application web, Nicolas a choisi Selenium. Cet outil va nous permettre de lancer et de piloter un navigateur depuis le code afin de tester tous les comportements de l’application. La seule chose qui lui manque par rapport à un être humain, c’est de ne pas être capable de repérer les problèmes de CSS … Toutefois pour des questions de gain de temps, il vaut mieux utiliser Selenium Grid qui a l’avantage de faire tourner des tests en parallèle sur plusieurs machines et donc d’être moins gourmand en ressource.

Tests de performance / endurance

Les tests de performance et d’endurance, s’ils sont effectués très tôt, permettent de détecter rapidement le moment où le code perd en qualité. Pour cela des outils tels que JMeter ou Clif permettent de collecter des données et d’avoir un historique des performances.

Quand tester ?

Dans l’idéal tout le temps, ce qui est recommandé avec Maven mais peut être long voire fastidieux d’où l’intérêt d’avoir des tests automatisés, ce qui nous amène à l’intégration continue. L’idée est cependant que les tests restent rapide, il faut donc faire un compromis entre le “tout testé” qui va prendre beaucoup de temps et le “testé partiel” où l’on va décider de remettre à plus tard les tests plus lourds, ce qui permet de déployer le snapshot pour qu’il soit testé le plus vite possible.

Un feedback visuel

Envoi de mail, de messages instantanés, utilisation de led … pour être efficace l’intégration continue passe par l’attention portée par les équipes de développement à l’état du build après chaque commit. Nicolas nous rapporte son expérience personnelle de l’un de ses projets où celui-ci était directement retransmis par des néons. Simple et ludique, cette solution était également un moyen d’alerter rapidement un développeur au cas où l’un de ses commits aurait cassé le build.

L’intégration continue

Certainement le plus populaire des outils d’intégration continue, Hudson est en effet bourré de qualités : très simple d’utilisation, il supporte maven 2 en natif et le support de maven 3 est déjà en cours, ce qui permettra de voir exactement quel module ne build plus et de faire de la rétroaction rapide. De plus, Hudson étant extensible par plugin, vous pourrez d’ores et déjà trouver votre bonheur parmi certaines extensions que Nicolas a répertoriées en plusieurs catégories : “indispensables” comme la notification ou le support SCM, “utiles” comme la recherche des TODO ou encore “geekesque” comme l’extension Chuck Norris. (Si vous cassez le build, Emmanuel Bernard Chuck Norris en personne vient vous botter le derrière ;) )

Assurer la qualité

Maintenant que vous avez tous les outils pour surveiller les performances de votre application, armez vous de métriques afin d’en surveiller la qualité, et notamment celle de votre code. Il existe des outils pour vous permettre de surveiller :

  • la duplication de code
  • la complexité cyclomatique (CCN)
  • le nombre de ligne par classe / méthode
  • le couplage entre objets (Ca, Ce)
  • le code mort
  • la couverture des tests
  • les dépendances

L’outil de réference pour ce genre de mesure est bien entendu Sonar qui va vous permettre, entre autre chose, de surveiller l’évolution de la qualité et de la complexité du code au fur et à mesure du développement (vue “time-machine”) ou encore de voir le top dix des méthodes qui violent les règles que vous aurez défini au préalable avec votre équipe (vue “violations drilldown”). Ce dernier point nécessite bien entendu d’effectuer en amont du développement des points de sensibilisation pour faire comprendre à chacun à quoi servent les règles.

Produire le livrable

Une procédure de Maven assez compliquée à mettre au point mais très efficace lorsqu’elle est maîtrisée est le cycle “release”. Celui-ci permet en effet de définir le processus de livraison : Maven va vérifier que tout est committé, tester tout, supprimer les snapshots, mettre un tag, faire un check out du tag, re-tester, etc … La vue complète des étapes de ce cycle est disponible dans la présentation de Nicolas (voir lien plus haut).

La livraison étant une étape parfois longue, Nicolas recommande l’automatisation du déploiement, avec l’aide de DbMaintain notamment, pour la gestion de la base de donnée. L’automatisation va permettre de déployer soit sur une plateforme de tests fonctionnels soit en plateforme de prod, de mettre à jour le repository central, etc …

Gérer la documentation

Pour documenter votre application, deux options s’offrent à vous : la doc dans le SCM, versionnée en même temps que l’application ou le wiki. Le wiki a l’avantage d’êter réactif, indexé, de tenir un historique et d’être accessible à tous : XWiki a en effet développé XEclipse et XWord pour éditer le wiki depuis eclipse ou word. Développeur ou Project Owner, plus personne n’a d’excuse pour ne pas l’ouvrir !

Des postes de développement “prêt à coder”

Vous avez sûrement tous à un moment ou à un autre, perdu du temps à installer votre poste de développement ou à tout simplement maintenir à jour l’environnement de développement de toute l’équipe. Pour résoudre ce souci, travailler dans une VM peut être la solution et pour cela deux solutions plutôt séduisantes arrivent :

  • Sonatype annonce la venue de OnBoard, une solution “prêt à coder” pour tous
  • the Blacksmith Project se propose de construire des forges logicielles à la demande : les utilisateurs peuvent voter pour les logiciels qu’ils souhaitent voir intégrer dans leur VM ou bien émettre des souhaits et la forge est prête à être téléchargée.

Paris JUG de mai : Build, Share & Deploy jusqu’au bout de la nuit (4)

Petit tour au buffet avant d’attaquer la deuxième partie de soirée.

Comme d’habitude, c’est encore là qu’on apprend des tas de choses, et qu’on peut revenir un peu au réalités : Quel est le revers de la médaille ? quand va-t-on me laisser l’utiliser ?

Pour fêter son 10ième client de l'eXpress Board, Nicolas Martignole finance le buffet.

Tout le monde est très sage ce soir. 21h, ils sont tous remontés dans la salle de conférence à l’heure dite, sans le coup de sifflet rituel d’Antonio. Très motivés par Maven 3 ?

Maven 3

Nicolas De loof et Arnaud Héritier, tous les deux commiters Maven, nous ont préparé un véritable show en duo basé sur les rôles de Jamy et Fred dans l’émission  C’est pas sorcier.

Arnaud où est ton pull jaune ?

Allez Marcel, ‘On va migrer vers Maven 3′  !

Nicolas De loof est très bon dans son rôle. Il a réussi à nous faire vivre ses relations compliquées avec son pote  Jason qui veut faire plein de trucs avec Maven. Il parle de  Jason van Zyl le fondateur de Maven. Présentation très vivante, sur un sujet qui n’était pas évident vous allez le voir.

Maven 3 est compatible avec toutes les versions précédentes. Plus de tests ont été faits pour le rendre plus robustes et assurer la compatibilité. Dans 99,99 % des cas ça passe tout seul. Dans les autres cas, ce sont des problèmes dus aux descripteurs de projet, car ils sont plus stricts en Maven 3. Et aussi Maven Site ne marche pas en Maven 3. C’est plus la peine de leur dire : ils savent.

Maven 3 a été entièrement refondu. L’objectif N°1 était d’améliorer la compatibilité.

L’équipe Maven a appris de ses erreurs. Maven 1 était immaintenable. Maven 2 a fait table rase, plus maintenable, un support des plugins. Une joli architecture mais pas souple et peu extensible, difficile à aborder pour les gens qui veulent rentrer dans le code. Nicolas nous partage les déboires qu’il a pu rencontré lors du développement de son plugin GWT.

Les nouveautés

Quelques modifications prévues : supprimer Plexus, mal documenté et peu utilisé en dehors de Maven, pour le remplacer par un IoC standard base sur la JSR 330. Spring ou sont Guice est envisagés, mais rien de clair pour le moment.

Nicolas de loof: Ils sont pas beaux mes wagons ?

Maven passe enfin sur Java 5 et va donc enfin pouvoir utiliser les Generics. Le code est plus propre. Les documentations ont été améliorées, en particulier pour distinguer les API publiques et privées.

Le modèle de plugin de Maven 3 est plus interactif. Le plugin Aggregator qui servait à coordonner des opérations entre modules est supprimé. Une nouvelle fonction le Build plan va rendre les plugins plus adaptables au contexte. Le build plan permettra au plugin de comprendre ce qui va se passer lors de son exécution et ils pourront se configurer en fonction de ces informations.  Un exemple : le build plan pourra lister les tests à faire avant de commencer ce qui évitera de les jouer plusieurs fois parce qu’on ne sait pas s’ils ont été faits ou pas. Les builds plans devraient  éviter d’avoir besoin d’Aggregator.

Cela promet une meilleure intégration dans Eclipse. Maven 2 ne permettait que de réaliser des builds complets. Les build plus adaptables de Maven 3 permettront de laisser Eclipse faire ce qu’il sait faire dans les étapes du build (compiler par exemple) et de ne réaliser dans Maven que ce qui reste. Le plugin Eclipse les retirera du build plan, ce qui évitera les conflits.

Maven rencontre OSGI. Maven Tycho implémente la gestion des modules et des dépendances basée sur OSGI. Eclipse est basé sur un modèle OSGI. Le moteur qui installe et les gère les dépendances est Eclipse P2 (pour Provisioning Platform). Grâce à Tycho, Maven aura une meilleure intégration avec Eclipse et les repositories de bundle OSGI au format P2.  Le plugin Eclipse M2Eclipse s’appuie sur Tycho.

Le POM devient polyglotte. Il pourra être écrits dans d’autres langages qu’XML (Python, Groovy). une nouvelle syntaxe va également permettre de définir des exclusions globalement et non pas au niveau de chaque dépendance.

Les logs sont plus lisibles.

La possibilité de faire des mixins c’est à dire  d’avoir des héritages multiples et non plus strictement hiérarchiques.

Les performances sont améliorées, en particulier par la possibilité de paralléliser certaines parties du build. C’est Maven qui analyse les branches parallélisables et les points de synchronisation. Par exemple, sur un bi-core, le temps passe de 11mn en Maven 2, à 10 mn en Maven 3 et 6 mn en Maven 3 sur les 2 cores en parallèle. Bien sûr tout celà dépend de la présence ou pas d’éléments parallélisables. Cette possibilité est aussi intéressante pour les fermes d’intégration continue (comme Hudson) qui hébergent des builds complexes et longs.

Arnaud, Nicolas et Antonio en train de comploter pour savoir comment ils allaient faire pour donner le bouquin à une fille.

De nouveaux outils : une  console Maven Shell qui permet d’avoir un résultat en couleur, et accélère un peu les builds en évitant de relancer la JVM et en mettant en cache les descripteurs Maven. Elle permet aussi de configurer des environnements Maven distincts selon les projets.

Pourquoi passer à Maven 3 ?

Il n’y a pas de fonctionnalité renversante, mais ça fonctionne mieux et plus vite. Le nouveau plugin Eclipse M2Eclipse devrait permettre aussi de gagner du temps et est à tester.

Maven 3 est en béta 1 pour le moment. L’équipe travaille toujours à porter les composants qui ne marchent pas comme Maven Site et eclipse:eclipse et attends vos retours.

L’organisation est toujours assez dirigée par le haut par Sonatype, et par Jason le pote à Nicolas,  mais elle se professionnalise et les processus sont plus clairs. Maven dispose d’une très forte communauté de développeurs et d’utilisateurs sénior.  Après la refonte en Maven 3 de nouveaux développeurs arrivent. C’est une bonne nouvelle, la communauté revie.

Vous pouvez retrouver les deux trublions dans leur livre Apache Maven aux éditions Pearson. Chose à noter, il est en français, c’est rare;

Un exemplaire a été donné à une des Duchess.

Appel pour l’ISEP

Antonio a profité du micro pour faire un appel pour l’ISEP. L’ISEP met ses locaux à disposition du JUG gracieusement. Le JUG vous propose de le remercier en réalisant des présentations ou des cours de quelques heures pour les étudiants de  l’ISEP sur des sujets  que vous maîtrisez. Ces cours ont lieu dans la journée.

N’hésitez pas à contacter l’équipe du JUG si vous avez des idées ou des propositions.

21h30 plus qu’une présentation, mais si on fait tout ça c’est bien pour déployer non ?

Précédent : la présentation Git Suivant : la présentation Deployit

Les photos sont de José Paumard et Claude Falguière.

Paris JUG de Mai – Découvrez Maven 3

Ce mois-ci nous avons décidé de vous faire de courtes présentations des thèmes du Paris JUG histoire de vous donner l’eau à la bouche. Alors ce mois de mai, plusieurs sujets liés à l’intégration continue. Pour commencer, Maven.

Maven 2 : certains le trouvent trop “usine à gaz” d’autres luttent au quotidien pour le faire fonctionner avec Eclipse. Pourtant, Maven 2 est au coeur de nombreux projets Java. La gestion des dépendances et son cycle de vie permettent de réaliser facilement des applications web. Que de progrès réalisés depuis les makefiles !

Depuis quelques mois déjà, la première béta de Maven 3 est disponible dans les bacs. Très prometteur, rétrocompatible avec Maven 2, son noyau a été entièrement réécrit pour attirer la communauté open source autour de cet outil et faciliter le développement de plugins encore trop laborieux actuellement. A l’occasion du ParisJUG, Arnaud Héritier et Nicolas De Loof vont nous présenter les nouveautés de Maven 3.

Vous voulez savoir :

  • si votre plugin m2eclipse va enfin fonctionner correctement dans votre IDE préféré ?
  • si vous pourrez migrer vos projets de Maven 2 vers Maven 3 sans souffrance ?
  • étendre un plugin pour une utilisation précise ?

A toutes vos questions, nos speakers, co-auteurs de l’excellent livre Apache Maven, répondront. Alors venez nombreuses à la soirée Share, Build & Deploy du ParisJUG ! Les inscriptions seront ouvertes bientôt ;) .

Inscrivez vous sur la mailing list et surveillez bien vos mails. Les places sont chères ! Et surtout n’oubliez pas de nous confirmer votre présence à l’AvantJUG.

Quelques références sur Maven 3 : Maven 3 par Romain Linsolas sur developpez.com Les slides de la présentation de Maven 3 de Jason Van Zyl

Ellène Dijoux

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer