3è Geneva JUG : Maven

L'URL courte de cet article est : http://inagua.ch/wTtTG

Après celui sur Play! et celui sur Sonar, voilà le 3ème Geneva JUG, le 3ème du nom. Ce soir, Arnaud Héritier, co-auteur avec Nicolas De loof du livre “Apache Maven“, vient nous parler de Maven.

apache-maven

Ce soir nous sommes à l’Uni. Dufour, ce qui m’arrange car c’est à 5 minutes à pied de nos locaux…

La salle est pleine !… Aux dires des organisateurs, il y aurait 90 inscrits… Et la police semble confirmer pour une fois ;))… Là, on ne peut pas parler d’un taux d’abstention élevé… Bien au contraire !!

Seul petit bémol : le pupitre ! Les gens assis sur la partie gauche de la salle (dont je faisais partie) ne voyaient pas une partie de l’écran à cause de ce <biiiip> de pupitre… Monsieur le président du JUG, cette dédicace est pour vous ;)

A propos de président, Xavier prend la parole à 18h39…

Il nous présente les nouveaux sponsors, à commencer par la librairie Ellipse.

Elle nous avait déjà fait un pourcentage sur les livres que nous avions offert au dernier Agile Tour Genève. Et cette année, elle a accepté que nous déposions posters et flyers pour les XP Day CH.

Dans la foulée, Xavier donne les codes de réduction pour l’achat me ligne de livres Manning, O’Reilly et Apress.

Puis il nous confirme l’agenda des prochains JUG :

  • Lambda j le 27 avril, qu’il présente comme ” un DSL pour les listes en java” (la session sera en anglais)
  • Java EE6 en mai
  • Jazoon en juin à Zurich (20% de reduction par le JUG)
  • Glassfish v3 en juin (une session très pratique)

Xavier fait aussi mention du DevDay iPhone, le 28 avril à Genève.

Ensuite, sur l’impulsion de Maxime, Xavier parle de soft-shake.ch : mais la surprise est qu’il me laisse la parole pour présenter l’événement ! Votre serviteur, pris au dépourvu a du improviser une présentation succincte…

L’événement informatique au sens large de cette fin d’année avec 3 thèmes, java, agilité et iPhone, plus un track incubateur. L’idée est de faire enfin se rencontrer les communautés. Les 3 thèmes seront supportés par leurs représentants locaux : le JUG, le groupe des développeurs iPhone romands ainsi que Agile-Swiss et les organisateurs de l’Agile Tour Genève.

Pour plus de détails ou des news, surveillez le site soft-shake.ch, ou abonnez-vous à l’un des canaux communautaires : nous “émettons” sur Tweeter, Facebook et LinkedIn (les pointeurs sont sur le site).

soft-shake

Un grand merci à Xavier pour nous avoir donné la parole, et “respect” pour parler des événements informatiques autres que Java (iPhone dev day).

Xavier donne ensuite la parole aux 2 nouveaux sponsors.

D’abord Cross System, qui s’est présenté comme si il parlait à son enfant : ” Je travaille pour être heureux… Mais que faut-il pour être heureux ?… D’après la littérature, nous avons besoins de :

  • être connecté
  • contrôler son destin
  • percevoir sa progression
  • faire partie d’un projet un peu plus grand que sa propre tâche “

J’ai bien aimé cet interlude extra-informatique… On retrouve des concepts qui apparaissent de ci et de là dans les événements sur l’agilité… Par exemple, la session de Dominic sur l’hédonisme. On touche à l’émotionnel, en sortant du cadre du travail alimentaire. Même si je fais la part des choses avec un discours commercial, je salue et apprécie la teneur de l’intervention. Je vais creuser…

Puis ilem a pris la parole pour partager avec nous son constat ” qu’il y a beaucoup de testostérone dans l’informatique “.

Maven

Il est 18h55 quand Arnaud Héritier prend la parole pour nous parler enfin de maven 2.

Il commence par se présenter. Il travaille pour exo platform où il aide à améliorer les livrables et la chaine de production. Il est entré dans maven en 2004 et dans le PMC en 2005.

Puis on vient rapidement à Maven. Il explique qu’au départ il a rencontré beaucoup d’équipes qui ne comprenaient pas maven. Pour certains clients, l’utilisation de maven était (et est encore) douloureuse. C’est ce qui l’a motivé à écrire son livre avec pour but initial d’expliquer maven simplement.

Puis il nous met en garde : il a 120 slides a dégainer en 1h30 !… Du coup, il nous propose de voter pour savoir sur lesquels des 5 grands thèmes il devra insister, et lesquels il devra survoler.

Il commence par demander qui ne connait pas maven : une petite moitié des auditeurs lèvent la main…

Je suis estomaqué : je pensais vraiment que maven, à défaut d’être utilisé par tout le monde était connu de tout le monde. Ce n’est pas le cas. Je prend conscience, je m’éveille ;). Tant mieux.

Les 5 thèmes de sa présentation sont :

  1. une overview, les concepts, les concurrence
  2. l’écosystème, un outil mais la base de pleins de choses
  3. bonnes and bad practices
  4. les cas d’utilisation
  5. retour vers le futur 2.x -> 3.x

Après nous avoir fait voté à main levée, Arnaud lance : “… en fait je vais tout faire !… mais plus rapide pour ceux qui ont peu de succès”… Nous comprenons alors que nous avons été manipulés ;))

Au passage, un des thèmes a fait un carton : les bonnes pratiques

Bien que j’ai fait partie des gens qui ont levé la main pour les bonnes pratiques, avec le recule, je trouve paradoxale qu’il y ait autant de personnes demandeur de bonnes pratiques sur maven, dans la mesure où c’est outil qui favorise les standards au détriment de la configuration. Je pense pourtant que maven met effectivement l’emphase sur les conventions… Mais si cet objectif de standardisation était pleinement atteint, il n’y aurait pas besoin de bonnes pratiques ?!… Non ?… Peut-être que, contrairement à l’avis général, maven est finalement trop permissif “encore” !… Mais on va en reparler !…

Overview

Le premier des 5 thèmes est donc une présentation générale, et le premier slide est la définition :

Maven est un logiciel de gestion et de compréhension de projet

Il ne se limite pas au build : il adresse également la qualité, l’intégration…

Il est orienté standards, des standards forts que l’on est obligé de suivre : “Convention over configuration” (un modèle de données obligatoire à suivre).

Vous ne pouvez pas me voir, mais je sourie. Il a lâché, à juste titre, ce mantra, cher à mon coeur de développeur Ruby on rails ou d’agiliste. Ces derniers jours, j’ai finalisé une formation Java que nous avons donné, et qui incluait maven. J’ai donc lu pas mal de présentations sur maven, et ce principe de “Convention over Configuration” et de standards est bien trop rarement associé à maven. C’est important pour moi, car le non respect de ce mantra, est selon moi une raison au mal qu’Arnaud à énoncé au début : ” La mise en place de maven est parfois (souvent ?) douloureuse pour les clients “.

Puis nous sortons les livres d’histoire : maven a été créé en 2001 dans jakarta.apache.org, dans alexandria puis turbine. Il devient un vrai projet en 2003. La v2 sort en 2005 pour corriger les erreurs de la v1, mais sans compatibilité possible. “Nous avons fait une première tentative avec maven 1 : maven 2 reprend tout de zéro pour corriger les erreurs”.

J’ai vécu cela à l’époque. “Argh, les <biiiip>, ce m2 change de tout au tout de m1 : on doit tout refaire”… Mais avec le recule, je pense que c’est un bon choix : cela leur évite maintenant de trainer les fantômes et autres boulets du passé, comme certains autres logiciels font le choix de trainer leur legacy, pour le malheur des développeurs, et au final des utilisateurs.

Arnaud reprend ensuite les grands concepts de maven, les conventions (obligatoires a suivre) :

  • 1 projet/module = 1 livrable/artifact
  • Standardisation sur l’arborescence de développement : répertoires “src”, “java”, “test”… Ainsi, tout projet maven à la même structure, d’un projet à l’autre, d’un client à un autre !

J’aurais peut-être aussi cité sur le répertoire “target” afin d’opposer les sources, aux fichiers générés par maven, qui se trouvent tous dans “target”.

  • Le cycle de vie : maven définit les étapes que le projet doit passer pour se construire (on parle de phase) : dans le descripteur on décrit le projet et maven le construit pour nous.
  • Le POM est un fichier XML. Dans lequel est notamment indiqué l’id du projet, un triplet formé du groupId, de l’artifactId et de la version. La version est une notion centrale dans maven.
  • Le réacteur : il permet de découper un projet en sous projets ou modules. Ces modules sont les parties d’un même projet, maven de calculant alors les dépendances pour faire le build dans le bon ordre.
  • Le POM est descriptif (des modules que l’on utilise) : pas de découverte par maven à la construction ! Les io sont toujours limitant sur une machine de développement, et c’est pour cette raison que les développeurs de maven on fait ce choix de se baser uniquement sur ce qui est décrit, sans chercher à parcourir l’arborescence pour découvrir des dépendances.
  • L’héritage : le descripteur récupère la configuration du premier/parent (celui qui est dessus). Cela permet une réutilisation du paramètrage.

Pour revenir au cycle de vie, dans ma formation, je le compare à une ligne de métro où on monte au terminus : on peut descendre à la station que l’on souhaite (elle que l’on indique à la construction via le “mvn phase_destination”, mais par contre on passe obligatoirement par tous les arrêts intermédiaires.

De plus, pour ma part j’insiste sur la différence en ligne de commande entre “mvn phase”, “mvn plugin” et “mvn plugin:goal”… Mais peut-être hors sujet dans ses slides ?

Une erreur classique en maven : le découpage (en modules) doit être fait non pas en “choux” et “carotte” (comprendre en fonction d’un découpage fonctionnel), mais en types d’artefact à produire (batchs, jars,…). Le découpage doit être technique et non pas fonctionnel !!!

Il conseille d’utiliser le plugin “clirr” pour valider la compatibilité inverse.

Il aborde ensuite l’artifact repository. Avant les librairies étaient dans le gestionnaire de version ou sur le poste du développeur. Dans maven, toutes les librairies sont rangées dans une arborescence : dans le repository local sur le poste de développeur et sur internet dans un repository central géré par l’équipe maven (plusieurs Go de librairies). Quand on construit le projet, maven regarde en local, et si y est pas, il download sur le central. Cela permet une logique declarative sur un projet.

Comment faisions-nous avant maven ?… Je me rappelle de discussions pour savoir si les librairies devaient être dans le gestionnaire de version ou dans un répertoire à part… Le problème en mettant les librairies à part, est que l’on tire bien souvent en retour une dépendance forte au filesystem… Et difficile dans ces conditions d’automatiser la construction et au delà de mettre en place l’intégration continue.

Et ce qui vient avec le repository, ce sont les dépendances. Avant, les librairies étaient donc dans le gestionnaire de version et pas forcement la version dans le nom (ni dans le manifeste du jar). Et puis il arrivait que l’on ait le contenu d’une 2.5 dans une 2.4 car sinon on perdait l’historique dans le gestionnaire de version en renommant un fichier/librairie. Sans parler des projets avec deux modules qui dépendaient d’une même librairie dans des versions différentes. Maven gère ce genre de conflits. Depuis sa version 2, maven gère même les dépendances transitives : si A dépend de B, et B de C, alors A va dépendre de C.

J’applaudie l’initiative d’Arnaud de sensibiliser l’auditoire à ces soucis “passés”, car on ne sen rend plus compte maintenant de l’intérêt vital de mettre les versions dans le nom du fichier.

Cela me rappelle une discussion que j’avais eu aux débuts de maven avec un développeur sénior, pro-ant. Quand je lui ai dit que maven rationalisait les dépendances, tant dans le nommage (avec la version) que dans le stockage, il m’a répondu qu’il faisait la même chose avec Ant. Nous venions de résumé en un échange la force de Maven par rapport à Ant : maven vient déjà avec de bonnes pratiques comme conventions.

Il a ensuite décrit cette gestion des dépendances dans maven :

  • définition déclarative des dépendances avec l’id triplet et le packaging. Le pom est lui même un livrable, que l’on peut publier, pour en hériter par exemple (dans une entreprise) à des fins de réutilisation.
  • transitive
  • scope : Quel est ton usage de cette dépendance ? (exemple de junit)
    • compile (par défaut) : compilation et exécution
    • runtime : à l’exécution (dans le package final mais pas dans le path de compilation)
    • provided : c’est l’inverse – à la compilation mais pas à l’exécution (driver de base de données, API servlet…)
    • test : pour les tests unitaires
    • system : pour les soft propriétaires (chemin absolu) : très risqué !

Attention à la gestion des dépendances car on peut avoir des EAR de 100 Mo. Il faut définir toutes les librairies dont on a besoin… Et pas plus car c’est récupéré par transitivité.

En fait le notre faisait 109 Mo… Mais comment il est au courant ?!

;))

Par contre ne pas tomber dans le travers inverse : ne pas enlever celles qui sont obtenus par transitivité des librairies utilisées. Quelques commandes très utiles basées sur le plugin “dependency” pour gérer ses dépendances au plus fin  (voire pour debugger) :

  • mvn dependency:analyze
  • mvn dependency:tree
  • mvn dependency:list

Définir des modules optionnels pour notre client (celui qui va utiliser nos implémentations).

Une question fuse :

  • Nicolas>> Quid du mécanisme des exclusions dans Maven 3 ?
    • Arnaud>> Il existe effectivement le mécanisme d’exclusion. Pas dans m3.0 mais dans 3.x car le pom ne change pas en 3.0 mais après le noyau évolue !

Puis Arnaud décrit le principe des versions.

  • standardiser dans maven
  • deux types :
    • snapshot : en dev, constamment en changement
    • release : c’est fixe – pour éviter de re-telecharger une même version
  • 1.0.0-snapshot -> 1.0.0 -> 1.0.1-snapshot-> 1.0.1
  • snapshot télechargé par défaut une fois par jour
  • un projet en version release ne doit pas utiliser de dépendances snapshot
  • range : à utiliser avec beaucoup de précautions, en interne dans une entreprise
  • mvn versions.set -DnewVersion=a.b.c-SNAPSHOT (depuis un an seulement)

Je ne connaissais pas ce plugin “version”… Je me rappelle avoir travaillé sur ce point en 2005, notion qui est loin d’être simple, vu le format que peut prendre une version dans maven. Le client de ma dernière mission avait d’ailleurs développé son propre plugin.

Autre notion très utile, les profiles.

  • cela permet de modifier le comportement par défaut de maven
  • par ex. : pas la même liste de tache sur la machine de développement et d’intégration continue
  • Petite précision sur la propriété “activeByDefault” : QUE SI AUCUN AUTRE PROFILE D’ACTIF (je viens d’apprendre quelque chose !!)
  • plusieurs types d’activation (plusieurs façons pour activer un plugin)

Arnaud revient ensuite sur le cycle de vie de build et les plugin.

  • Tous ces standards servent à quoi ? Pourquoi toutes ces contraintes ?
  • En se reposant sur cette standardisation maven peut ajouter du coup de valeur ajoutée : se sont les phases
    • generate sources
    • compile
    • test
    • integration test
    • install
    • deploy

L’architecture de plugin permet une grande extensibilité. Il existe de nombreux plugins maven accessibles à différents endroits :

  • dispersés sur internet
  • sur le repository maven
  • le groupe “mojo” (plus souple sur les licences, et plus ouvert à la participation de la communauté)

De plus, il y a différents types de plugins :

  • package
  • report
  • IDE integration

Maven ou pas ??

  • Fusion de POM, déplacement de quelques sources : maven est anti sclérose ! On peut facilement ajouter ou supprimer des modules
  • Les dépendances
  • Un seul fichier descripteur
  • Standardise : quand j’arrive sur un nouveau projet maven je connais !
  • build, test, package, deploy, doc, check & report accessible sur tout nouveau projet

Les équipes se concentrent alors sur leurs développements et pas sur les scripts de construction.

C’est également un choix corporate :

  • aspect RH : le fait de travailler sur un standard, cela facilite le(s) recrutement(s)
  • développements standardisés
  • réduction des coûts : partage et réutilisation (connaissance, configuration/héritage, savoir-faire/plugins et librairies/repositories, qualité/indicateurs/amélioration)

La concurrence :

  • ant (vient de tomcat, reposant sur xml il n’y a pas de structure de control) + Ivy (gestionnaire de dependance)
  • easy ant (plus de souplesse)
  • gant (groovy, tres puissant)
  • graddle (gant avec maven)
  • buildr (ruby)

Mais il n’y a pas d’équivalent maven avec convention-point-barre : ils laissent l’utilisateur faire ce qu’il veut… Et refont donc l’erreur de maven 1.

Cela me fait penser au principe objet “Open-Close”, ouvert à l’évolution, fermé à la modification : l’idée est de pouvoir compléter et adapter l’outil à son besoin sans casser le fonctionnement de base.

Une nouvelle question fuse :

  • Nicolas>> Ant ouvre à la modification, maven refermait, et beaucoup d’outils re-ouvrent !
    • Arnaud>> Non ! Pourquoi maven ne veut pas réouvrir, laisser l’utilisateur/développeur faire ce qu’il veut comme il veut ?… Il y a deux possibilités :
  1. Soit l’utilisateur/développeur ne veut pas se plier aux conventions maven !.. Ok, on y peut rien.
  2. Soit on se dit : maven est capable de standardiser le build, java standardise la plateforme de runtime, l’un dans l’autre ça devrait être simple de se plier aux standards.

A main levée, Arnaud sollicite à nouveau l’auditoire : Qui développe du JEE en entreprise… 80% de mains levées !!

20:00 :  premier slide avec une image !… Et la salle y est sensible :

” With scripts oriented builds ” : Une magnifique R8 opposée à une vieille… WW ? Avec des cartons…

Avec du recule, Arnaud lance que si le script est centralisé, maintenu par une unique personne/équipe, cela fonctionne peut être mieux que maven…

Mon point de vue sur le sujet est tout autre. Pour moi cela induit un goulot d’étranglement : seule cette personne/équipe sera apte à intervenir en cas de problème. Je pense que c’est exactement la même chose que pour un framework maison conçu et maintenu par une équipe d’architecture : rares sont ceux qui n’ont pas encore compris que cela ne fonctionne pas.

Puis un slide avec un TGV (maven 3) opposé à un RER avec la bousculade (m2).

J’ai bien aimé cette métaphore, et l’ai du coup reprise à mon compte dans ma formation :

  • une voiture avec toutes les pièces mises côtes à côte (m1) : chacun peut reconstruire la voiture comme il le souhaite, avec plus au moins de succès au final
  • les bus électriques suisses, avec leur bras débrayable qui les relie au réseau électrique aérien (m1) : ils suivent le réseau électrique, mais peuvent à tout moment débrancher le bras et rouler librement (ce qu’ils font quand il y a un accident par exemple)
  • le TGV (m2) : une grande vitesse, mais impossible de passer outre le réseau ferré

ant-m1-m2

L’écosystème

Arnaud aborde alors les outils qui s’associent à maven en commençant par dire ” alone is nothing “.

Les repository managers :

  • nexus
  • artifactory
  • archiva

Arnaud : “Je fais partie de l’équipe mais je ne le proposerais pas. Choisir l’un des 2 premiers en gratuit – très rapide à mettre en place entreprise, prend peut de ressource”.

Ces outils :

  • sécurisent les build DANS l’entreprise (si pas d’internet, le build continue de fonctionner avec l’intranet)
  • permettent de filter des librairies, des repositories
  • peuvent assurer le staging pour pre-prod et prod

Chez eXo on utilise nexus :

  • internet comme repository central qui permet d’alimenter…
  • reponexus.exo.org comme repositoy corporate
  • reponexus.exo.vn pour le Vietnam, car là bas internet subit des coupures
  • et d’autres repositories pour l’intégration continue, pour des clients, …
  • validation / staging de nexus : (repo dev – repo qa) puis repo public

Qualité

  • Test automation : les tests unitaires sont dans le cycle de vie du build
  • Y a rien à faire pour utiliser les tests unitaires en maven : “c’est pré-cablé” !
  • JUnit, selenium, canoo, jmeter, jmeter, soapui…

Arnaud a bien insisté sur l’intérêt des tests !

  • Il y a plein de librairies/extensions pour la qualité :
    • checkstyle
    • PND, findbug, clirr
    • test coverage (cobertura, emma, clover)
    • mode blockage ou non : source d’amélioration
    • exemple de rapport : les dépendances
    • clin d’oeil a sonar : l’idée est de voir dans le temps – on se fiche d’un report à un instant t. Ce qui est intéressant est de voir l’évolution dans le temps. Or, il n’y a pas d’historique (des métriques) dans maven. Les équipes font-elles un effort d’amélioration ? Voilà la question à laquelle doivent répondre les rapports.

Entièrement d’accord sur ce point. Bien vu la précision.

En effet, je pense qu’un taux de couverture à un instant t n’apporte rien. Ce qui compte c’est l’évolution. Du coup, cela met un grand coup dans l’aile à l’interêt des rapports de maven, donc du site généré.

Avec le recule, je ne comprend pas que ce point, l’historisation des données, n’ait pas été pris en compte dans maven 3. Peut-être que l’existence et le succès de sonar à joué ? Pourtant cette problématique existe depuis les débuts de maven. Avant même d’avoir la chance de participer aux premiers battements de coeur de Sonar, nous avions cette problématique en tête chez mon dernier client, sur Paris.

  • L’amélioration continue :
    • un environnement neutre
    • on sort le projet du gestionnaire de version et le build
    • réagir rapidement : plus tôt est reconstruit le projet, plus tôt on détecte un bug

… Plus près on est de la cause du bug, plus facilement on le corrige.

    • Quelques serveurs d’intégration continue : hudson, bamboo, CruiseControl, Team City
    • Quand on a un bug :
      • si un test plante dans les 5 minutes : la correction est plus simple
      • si retour après livraison au client : plus difficile à corriger, et dommages collatéraux (l’insatisfaction client ;o)
    • Macro vision : mon projet peut-être ok, mais un projet qui utilise mon projet lui peut planter

Très bonne chose de sensibiliser à l’intégration continue. Moi même, dans la formation maven/java, je me suis demandé si je devais présenter l’intégration continue. Sur l’une de mes dernières missions, le client a mis en place maven, vraiment comme un remplaçant de ant. Mais l’intégration continue n’était pas du tout une pratique connexe. J’ai du mettre en place Hudson sur mon projet, sans que cela soit prise en charge de façon centrale, par l’équipe responsable de maven de l’entreprise.

  • L’intégration continue doit être automatiquement déclenchée à chaque commit, par contre sonar peut fonctionner une fois par jour, chaque nuit par exemple.

L’IDE

L’intégration aux IDE est le grand soucis de maven.

Le cas Eclipse : c’est la gue-guerre :

  • De grandes différences dans les concepts, dans les produits
  • Deux façons de travailler avec maven et eclipse :
    • soit générer les fichiers projets eclipse et les importer dans eclipse (un plugin maven)
    • soit utiliser la gestion en natif de l’IDE (un plugin eclipse)
  • eclipse:eclipse
    • le plus gros plugin dans maven !!… Plein de if sur les versions d’eclipse
    • pas de doc sur les fichiers .project dans eclipse
    • pas de sous modules dans eclipse
    • plugin en déperdition, voué à disparaitre
    • bugs sur les classpath
    • asynchrone : modifier pom, générer, recharger

C’est marrant : j’ai très longtemps utilisé ce plugin. C’est même le seul qui fonctionnait sur le gros projet sur lequel je travaillais : beaucoup de dépendances, pas optimisées, avec des technologies variables comme le weaving aspects et des pom corporate “bizarres”, faisaient planter le plugin eclipse !

  • du coup on part sur m2eclipse :
    • synchrone
    • éditer le pom aisément, avec l’autocomplétion
    • supporte les poms intermédiaires
    • ne supporte pas tous les packaging
    • ne supporte pas les projets avec beaucoup de modules — LE PROBLEME : MAVEN N’EST PAS INCREMENTAL (compilation seulement de tel projet, ressource filtering)
    • m3 va améliorer cela
    • rapprochement d’eclipse
    • à utiliser sur les projets réduits

J’aurais ajouté en bonne pratique, qu’il ne faut pas mettre sous gestionnaire de version les fichiers projet eclipse (.project…), comme tout autre fichier généré.

Suite à une remarque “moi ça ne fonctionne pas dans ma version…”, on part dans une guerre de versions : “dans la 0.8 ne fonctionne pas mais le 1.0 de…”… Hallucinant d’avoir ce genre de problème en 2010, sur des outils et des technologies qui ne datent pas d’hier !

A mesure de sa présentation, je me rend compte que la modification du POM se fait de moins en moins directement dans le fichier XML. De plus en plus, cela passe par le plugin eclipse. Est-ce bien ?

Petit à petit, on en arrive à dire qu’Eclipse pose de sérieux problèmes… Ce qui pousse à parler des alternatives et de leurs plugins maven :

  • Idea IntelliJ : moins de choses que m2eclipse mais le fait bien
  • Netbeans : assez simple, moins de services, reste simple, et le modèle de projet dans netbeans est plus puissant et plus proche de maven

Citation d’Arnaud : “ Je vais me tirer une balle sous eclipse : j’etudie IntelliJ “.

Je suis bien content d’entendre cela d’une personne dont l’expertise sur Eclipse semble indéniable.

Eclipse c’est pas mal pour un produit gratuit… Disons surtout que c’est le seul que je connais, mais dans l’absolue c’est pas un bon produit. Je comprend l’argumentation qui consiste à dire : c’est open-source, il y a beaucoup de contributeurs, il y a beaucoup de fonctionnalités/plugins/on peut faire beaucoup de choses avec… Ok, c’est vrai, mais cela n’empèche que ce n’est pas un bon produit !

Par exemple, comment justifier qu’il y ait l’option “Clean” ??… Ca veut dire quoi ? C’est clairement un bouton verrue qui veut dire : “le build ne fonctionne pas, efface tout et reconstruit”. L’autre avantage d’un IDE (et je l’ai déjà dit), c’est les refactorings… Eyh bien oui ça refactore, mais c’est en retard avec ce qui est pour moi LE IDE : IntelliJ.

Quand on voit le temps que les développeurs peuvent perdre à faire fonctionner leur projet sous Eclipse, je ne comprend pas qu’il y ait encore des projets où l’on puisse entendre que le prix d’une licence IntelliJ freine à son acquisition… Surtout si l’on rapporte ce prix au budget moyen d’un projet JEE.

Bonnes et mauvaises pratiques

Puis Arnaud aborde un sujet que je n’avais pas souvent vu jusqu’ici : les bonnes pratiques maven.

  • KISS : Keep It Simple, Stupid… Chiche ;)
  • Éviter de :
    • Ignorer les conventions (excepté durant une phase de migration)
    • Utiliser différentes versions d’une dépendance dans un même projet (dans deux sous projets)
    • Avoir trop de modules/héritage (perte de temps)
    • Abuser des profiles
    • Utiliser tous les reports dés le départ (et commencer avec des millions de warnings)
    • Passer son temps dans la console (build trop long)
    • Délaisser les tests : si c’est trop long, réduire la durée ou utiliser les profiles et l’intégration continue (ne jouer certains tests que dans un profile d’intégration continue)

Une autre bonne pratique à mon sens :  Éviter de développer des scripts par dessus. En effet, j’ai vu quelques fois, des développeurs (bien intentionnés) développer des scripts (DOS en l’occurrence) qui lançaient des commandes maven. Petit à petit, ces script se sont étoffés, jusqu’à : 1) il devienne impossible de lancer les commandes maven en dehors de ces scripts, et 2) seul le développeur en question était capable d’intervenir quand il y avait un problème dans le build. Maven devenait de la tuyauterie interne, invisible de l’extérieur. On perdait cet aspect structurant qu’a vendu Arnaud plus haut. Donc, pour moi, je préconise une interdiction formelle d’utiliser des scripts par dessus maven. Les seules instructions que l’on a le droit de taper dans la console sont des lignes de commande maven et non pas des mvn-build-mon-projet. Ainsi, les seules compétences requises sont des compétences maven.

  • Penser à :
    • Utiliser le dependency management dans le pom racine (unique endroit où spécifier les versions des dépendances utilisées)
    • Idem pour les plugins
    • Garder la version de maven à jour

Pour ma part, quand je vois la simplicité de gestion que cela apporte, et les problèmes que l’on a quand on ne l’utilise pas, je ne comprend pas que le dependency-manager ne soit pas obligatoire, et que l’on puisse spécifier une version directement dans une dépendance ?!…

M3

Arnaud termine rapidement la présentation en survolant les spécificités de maven 3.

La dernière version de maven est la 2.2.1. La plus stable est la 2.0.11. Maven 2 est fini.

La 3 était prévue pour janvier, maintenant annoncée pour avril, mais Arnaud n’y croit pas avant septembre :

  • POM refait
  • lifecycle
  • lit et gère les dépendances
  • pom en différents scritps
  • parents sans version
  • mixins : heritage multiple (attention)
  • meilleur intégration aux IDE
  • meilleurs performances
  • meilleurs messages d’erreurs
  • gestion des plugins : extensions entre plugins
  • peut être build parallèles
  • outils : tycho, mvnsh (shell intégré)
  • communauté croissante
  • 1700 inscrits sur la mailing list utilisateurs l’année dernière
  • 2 000 000 de vues par mois le site
  • 20’000 à 50’000 download
  • l’équipe de développeurs : 60 committers, 30 actifs, des sociétés qui collaborent

On réécrit tout avec plus de tests : donc peu de nouvelles fonctionnalités, avant l’année prochaine.

Conclusion

Maven :

  • est largement utilisé en entreprise (ce n’est pas un choix opensource).
  • apporte beaucoup de services, d’intérêts à l’utiliser
  • est opensource mais actif
  • n’est pas parfait mais on y travaille, de gros efforts sur m3… mais cela ne répondra qu’à 80% des développeurs java

Il conclue par un petit message : ” Help wanted : participer à maven ce n’est rien ! Il y a différentes manières pour cela.

Questions & Réponses

  • Participant>> Il y a 2 soucis dans maven : trouver la doc et la roadmap
    • Arnaud>> La roadmap c’est difficile car il n’y a pas de ressources affectées, et sur le contenu, ce n’est pas facile, car sonatype, le plus gros contributeur, choisit ses priorités.
  • Participant>> Pourquoi Plexus n’est pas remplacé par Spring ?
    • Arnaud>> Plexus va être remplacé Google Guice

Le session se termine sur les chapeaux de roues à 20h49.

Xavier reprend la parole pour la désormais traditionnelle tombola :

  • Monsieur Bois gagne une licence JRebel
  • Puis c’est le tirage au sort pour un exemplaire du livre d’Arnaud… “Jacques Couvreur”… : un BOUUUUUH monte dans la salle ! Pourquoi tant de haine ???… De toute façon, comme disait Coluche : “j’ai les noms des meneurs” !… ;)
  • Et Xavier de conclure : “Ceux qui n’ont pas gagné peuvent en acheter un ;)”.

Du coup, je suis allé me faire dédicacé mon exemplaire par son auteur… La première et dernière fois que j’ai gagné un livre, c’était aux premiers XP Day Paris : un exemplaire du livre de Richard Piacentini sur Ruby On rails… Drôle de coïncidence pour deux outils prônant le “Convention Over Configuration“.

Mon point de vue

Une belle prestation d’Arnaud qui a dégainé plus d’une centaine de slides en 1h30… Un rythme soutenu, mais pas précipité. Il a gardé une altitude de vol constante : pas trop de détails, et pas trop de généralités.

La question est de savoir si les participants ont suivis… Pour moi qui connaît bien maven, c’était bien. Et j’ai revu un de mes stagiaires, qui ne connaissait presque pas java quelques jours plus tôt, et pas du tout mayen et qui était présent à la soirée : la session s’est également bien passée pour lui. Donc chapeau Arnaud !

D’autant plus que les slides étaient très textuels (je n’ai pas dit verbeux !). Les premières images sont arrivées après la première heure. Sans être une présentation Zen, c’était bien.

Je suis content de voir que cette présentation a été l’occasion de rapprochements avec l’agilité : KISS, tests unitaires et intégration continue, courage (de conserver des tests rapides). Arnaud a d’ailleurs plusieurs fois insisté sur l’intégration continue et l’amélioration continue, au delà du simple build de projet : c’est assurément une philosophie qui ne vient pas naturellement avec ant.

Au delà, je crois vraiment que le succès de maven tient à la rigueur qu’il implique dans nos processus de développement. J’ai donc peur d’entendre que la v3 va assouplir certaines de ces contraintes. Je ne peux m’empêcher de faire le parallèle avec les arguments variables dans les méthodes en java (les “…”) : on peut tout faire avec, y compris ne plus faire de classe !

Pour revenir au livre d’Arnaud, j’ai toujours été surpris par le peu de livres sur maven. A tel point qu’avec Freddy on avait commencé un plan détaillé pour en écrire un en 2006… Puis nous sommes partis sur d’autres projets. Même encore maintenant : attendre 2010 pour un livre sur maven 2 en français alors que l’outil est sorti en 2005… Je ne m’explique pas cela, surtout pour un logiciel aussi structurant dans le processus de construction ! On ne parle pas d’une n-ième librairie java utilisée seulement par des geeks dans leur cave.

Enfin, j’ai pas mal utilisé maven sur de gros projets. Cela s’est très bien passé sur le plus gros des projets, où l’on respectait au maximum les conventions maven, et utilisait au maximum les plugins maven. A l’inverse, j’ai eu de très gros problèmes sur de plus petits projets, sur lesquels on a cherché à rompre le cycle de vie maven, et où l’on favorisait les plugins maison aux plugins maven !…
Si on veut rouler vite sur autoroute, il vaut mieux 1) utiliser des voitures obtenues chez ceux dont c’est le métier d’en construire, et 2) respecter le code de la route !

Freddy m’avait demandé d’attendre la prestation d’Arnaud pour être plus tranché : j’espère avoir été à la hauteur de ses attentes ;))

Merci à ceux qui ont eu le courage de lire jusqu’ici.

Merci pour vos éventuels commentaires.

Merci à Arnaud pour sa relecture corrective et sa dédicace ;) Au fait : lequel du Reblochon ou du Toblerone est arrivé à bon port ??

Et n’oubliez pas : soft-shake.ch

L'URL courte de cet article est : http://inagua.ch/wTtTG

8 réflexions au sujet de « 3è Geneva JUG : Maven »

  1. Bravo pour ce compte-rendu d’une richesse jamais tutoyée dans le microcosme des JUGs !

    Concernant le pupitre c’était évidemment un gros point noir, et pas le seul dans cette salle: entre le message de remplacement de la lampe et les gens au fond qui ne voyais que les 2/3 supérieurs de l’écran, c’était pas optimal. ça nous apprendra à réserver nos salles trop tard …

  2. Ping : uberVU - social comments

  3. Merci Jacques pour ce résumé, comme d’habitude très détaillé ;)

    Pour le pupitre nous avons remarqué ce détail.

    Je rappelle aux lecteurs de ce post, ils peuvent suivre sur Twitter le GenevaJUG sur @GenevaJUG et SoftShake sur @softshakeevent pour plus d’informations !

  4. Merci pour vos retours, vraiment.

    En repensant à mon post ce matin, je me suis rendu compte que j’avais oublié un point important. Je viens donc de modifier mon post en ajoutant un item dans les bonnes pratiques. “Eviter d’ajouter des scripts maison au dessus de maven”…

    … A dans un mois ;)

  5. Merci pour ce compte rendu.
    J’ai quelques remarques sur tes commentaires personnels:

    Quand tu dis “Maven rationalise les dépendances tant dans le nommage (avec la version) que dans le stockage” et ceci en comparaison avec Ant –> Attention ta comparaison de Maven vs Ant pour la gestion des dépendances n’est pas complètement vraie.
    Tu devrais rappeler que Ant est uniquement un builder alors que Maven fait office d’outil de build et de gestionnaire de dépendances.
    Pour la gestion de dépendances hors Maven, tu as l’excellente librairie Ivy (au passage bien plus avancée que Maven).
    Et on compare donc en terme de services rendus, plutôt Maven vs Ant+Ivy

    Concernant ta bonne pratique de ne pas mettre les fichiers de configuration Elcipse en gestion de configuration logicielle. C’est entièrement vrai, je suis d’accord avec toi.
    Néanmoins, il est bon de nuancer ce propos car due a la pauvreté de l’outillage Maven via le plugin Maven pour Eclipse ou le plugin Eclipse pour Maven, on est malheureusement contraint parfois de devoir le faire.
    Prenons l’exemple d’une application d’entreprise EAR contenant des modules Web (WAR) avec des librairies communes au niveau de l’archive EAR, et pour une cible Eclipse 3.5.x, impossible d’obtenir une configuration IDE correcte sans des modifications manuelles.
    Ainsi, en attendant une meilleure intégration de Maven dans Eclipse, configurer une seule fois les fichiers de métadonnées Eclipse et centraliser cette configuration peut donc avoir du sens.
    Ensuite, dans l’état de l’art, en bonne pratique, on ne met pas ces fichiers dans le même dépôt que les sources car il s’agit de données de type d’infrastructure.
    Mais bon, en pratique, une mise en gestion de configuration contrôlée peut être faite.

    Et enfin, concernant la remarque “Éviter de développer des scripts par-dessus Maven”
    Sur ce point, je ne suis pas du tout d’accord.
    En aucun Maven n’est une finalité d’un processus d’intégration. Maven n’est qu’une brique comme une autre. Un processus d’intégration est souvent complexe. Maven peut avoir complètement du sens avec les qualités qu’on lui confère pour le build mais ce n’est qu’une simple brique.

    Des scripts automatisés d’aide à la mise en place de l’environnement d’exécution du processus d’intégration continue, au packaging de son produit (ensemble de jars, war, librairies diverses et externes, ressources complètement extérieurs suivant éventuellement une procédure de packaging dédiée et outillée), de déploiement, … n’ont pas nécessairement vocation a être orchestrés par Maven.
    N’essayons pas d’utiliser Maven pour ce qui il n’a pas été conçu.
    Même si Maven se positionne désormais comme un système complet et donc essaie de tout faire comme la partie gestion des dépendances, de la qualimétrie, de l’assemblage plus ou moins complexe avec son assembly plugin, du pseudo déploiement, …, Maven est avant tout un builder.

  6. Ping : Présentations Maven (3) à l’AlpesJUG et au GenevaJUG | mvn arnaud:blog

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*


*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>