Maven, anneau de Sauron ou couteau suisse ?


Manque de standardisation, augmentation de la taille de vos équipes, problèmes de qualités, vous avez tous déjà vu ça à un moment ou à un autre.
Et parmi les coupables bien souvent on retrouve les pratiques de build.
C’est dans un contexte un peu similaire que je vous propose une présentation que j’ai faite pour mon client actuel.

Pour résumer un peu l’ambiance :

  • plusieurs applications, un site web grand public
  • première expérience avec Ant, plusieurs scripts qui marchent mais un cout de maintenance galopant et plein de scripts dont « on ne sait plus à quoi ils servent »
  • première expérience avec Maven mais sans la mise en place des bonnes pratiques usuelles, pas mal de platres essuyés et des mauvais souvenirs.
  • fusion de plusieurs services et une nécessité forte d’industrialisation pour une équipe de dev+test+IT qui va avoisiner les 50 personnes (? pas sur du chiffre)

Pour la petite histoire, dans tout ça on a l’inévitable service qui ramène des tas de scripts legacy écrits avec Ant+Ivy sur plusieurs années et qui tente de l’imposer comme standard.
Petite discussion animée, défi, je réalise un petit prototype tout simple en moins de 2h qui remplit toutes les fonctionnalités des vieux scripts Ant+Ivy développés sur les x dernières années…
Merci, j’ai gagné le droit de faire une présentation sur Maven ^^

Maven

View more presentations from hlassiege

8 réflexions sur “Maven, anneau de Sauron ou couteau suisse ?

  1. Au slide 5, il est dit: « Maven est flexible » : Il faut le justifier car c’est justement sur ce point que se positionne les outils de build concurrent.

    De plus, je ne suis pas complètement d’accord pour considérer les scripts Ant/Ivy comme legacy.
    En réalité, le couple Ant/Ivy n’apporte pas les mêmes fonctionnalités. Ce n’est pas pour le même usage.

    • C’était une présentation, je l’ai justifié, mais à l’oral ^^

      L’idée de ce slide c’était de dire que Maven proposait des conventions facilitant donc la configuration de l’outil mais que si nécessaire on pouvait étendre l’outil (se plugger sur des phases) ou surcharger la conf (pour donner une autre arborescence). De ce point de vue la, Maven est flexible, pour autant c’est pas forcément une bonne idée de vouloir aller contre les conventions. Par exemple brancher la phase de test ailleurs ou appeler junit directement plutot que d’utiliser surefire. En fait Maven propose surtout des « best practices » de build. Dès qu’on en sort il faut se demander pourquoi.

      Considérant ant+Ivy tu remarqueras le slide « je-ne-veux-pas-de-polémique » qui dit bien la même chose que toi, ils n’ont pas les mêmes objectifs.
      Bon ca, c’était pour « je-ne-veux-pas-de-polémique », mon avis perso est différent tu l’auras bien compris ^^

  2. Au slide 5, il est dit: « Maven est flexible » : Il faut le justifier car c’est justement sur ce point que se positionne les outils de build concurrent.

    De plus, je ne suis pas complètement d’accord pour considérer les scripts Ant/Ivy comme legacy.
    En réalité, le couple Ant/Ivy n’apporte pas les mêmes fonctionnalités. Ce n’est pas pour le même usage.

    • C’était une présentation, je l’ai justifié, mais à l’oral ^^

      L’idée de ce slide c’était de dire que Maven proposait des conventions facilitant donc la configuration de l’outil mais que si nécessaire on pouvait étendre l’outil (se plugger sur des phases) ou surcharger la conf (pour donner une autre arborescence). De ce point de vue la, Maven est flexible, pour autant c’est pas forcément une bonne idée de vouloir aller contre les conventions. Par exemple brancher la phase de test ailleurs ou appeler junit directement plutot que d’utiliser surefire. En fait Maven propose surtout des « best practices » de build. Dès qu’on en sort il faut se demander pourquoi.

      Considérant ant+Ivy tu remarqueras le slide « je-ne-veux-pas-de-polémique » qui dit bien la même chose que toi, ils n’ont pas les mêmes objectifs.
      Bon ca, c’était pour « je-ne-veux-pas-de-polémique », mon avis perso est différent tu l’auras bien compris ^^

  3. Le problème de Maven, c’est surtout la communauté. Depuis quelques années on voit bien que la réactivité n’est pas au rendez-vous, c’est même tout java .net qui avance avec la lenteur d’un mamouth.
    Exemple ?
    Utiliser xjc:javaType dans un schéma pour générer une annotation XmlAdapter et changer la classe d’une propriété, eh bien avec le plugin jaxb pour maven ça ne fonctionne pas (obligé d’utiliser annox et baseType pour tout faire manuellement), les tickets sur le sujet datent de 2006.
    La doc des plugins est souvent laissée telle quelle (après génération du site), et je parle pas de la doc java.net qui est souvent inexistante ou mal faite.

    Il y a en France au niveau des DSI une espèce de frilosité sur l’OSS qui empêche de créer par exemple Gradle, avec ses nouveaux plugins qui apparaissent chaque jour sur Github.

    Je crois que ce qui retient surtout tout le monde sur Maven c’est la croyance que il n’y a que Maven qui peut utiliser les dépots Maven, en plus beaucoup utilisent Archiva ou Nexus, changer d’outil de build, ou permettre une utilisation de différents outils de build forcerait à passer sur Artifactory.

    Corbertura+Checkstyle+Plexus ça rassure son monde…

  4. Le problème de Maven, c’est surtout la communauté. Depuis quelques années on voit bien que la réactivité n’est pas au rendez-vous, c’est même tout java .net qui avance avec la lenteur d’un mamouth.
    Exemple ?
    Utiliser xjc:javaType dans un schéma pour générer une annotation XmlAdapter et changer la classe d’une propriété, eh bien avec le plugin jaxb pour maven ça ne fonctionne pas (obligé d’utiliser annox et baseType pour tout faire manuellement), les tickets sur le sujet datent de 2006.
    La doc des plugins est souvent laissée telle quelle (après génération du site), et je parle pas de la doc java.net qui est souvent inexistante ou mal faite.

    Il y a en France au niveau des DSI une espèce de frilosité sur l’OSS qui empêche de créer par exemple Gradle, avec ses nouveaux plugins qui apparaissent chaque jour sur Github.

    Je crois que ce qui retient surtout tout le monde sur Maven c’est la croyance que il n’y a que Maven qui peut utiliser les dépots Maven, en plus beaucoup utilisent Archiva ou Nexus, changer d’outil de build, ou permettre une utilisation de différents outils de build forcerait à passer sur Artifactory.

    Corbertura+Checkstyle+Plexus ça rassure son monde…

  5. +1 pour la doc, elle est parfois compliqué à trouver sur les plugins exotiques ou pour certains qui ont mal vécu la migration des sites sun vers oracle (comme le plugin jaxb).

    Mais dès que l’on reste dans du standard on finit toujours par trouver. Parfois la difficulté c’est de comprendre que le plugin X a été abandonné par tel ou tel boite et qu’il a été repris par une autre ou qu’il est passé d’un stade incubateur à un stade stable en changeant de groupid par la même occasion (plugin tomcat par exemple)

    Mais je ne vois pas le rapport avec java.net ? La plupart des plugins proviennent d’apache ou de codehaus dans la grande majorité. Effectivement si tu fais référence au plugin jaxb qui était sur .net, tu peux l’oublier…. 😉

    Après je te rassure, les DSI ne comprennent pas plus maven, ant ou graddle, c’est au dela de leur niveau de compréhension. L’argument technique sur les repositories leur passe 15000 au dessus de la tête.
    Par contre un argument qui leur plait toute : la standardisation, et ca maven se pose en pointe là dessus.

    Et effectivement, utiliser Cobertura+Checkstyle+Maven+sonar+Jenkins+…. ca rassure son monde. La raison est très bonne, ca fonctionne, ca a fait ses preuves et la maintenance en est facilité.

  6. +1 pour la doc, elle est parfois compliqué à trouver sur les plugins exotiques ou pour certains qui ont mal vécu la migration des sites sun vers oracle (comme le plugin jaxb).

    Mais dès que l’on reste dans du standard on finit toujours par trouver. Parfois la difficulté c’est de comprendre que le plugin X a été abandonné par tel ou tel boite et qu’il a été repris par une autre ou qu’il est passé d’un stade incubateur à un stade stable en changeant de groupid par la même occasion (plugin tomcat par exemple)

    Mais je ne vois pas le rapport avec java.net ? La plupart des plugins proviennent d’apache ou de codehaus dans la grande majorité. Effectivement si tu fais référence au plugin jaxb qui était sur .net, tu peux l’oublier…. 😉

    Après je te rassure, les DSI ne comprennent pas plus maven, ant ou graddle, c’est au dela de leur niveau de compréhension. L’argument technique sur les repositories leur passe 15000 au dessus de la tête.
    Par contre un argument qui leur plait toute : la standardisation, et ca maven se pose en pointe là dessus.

    Et effectivement, utiliser Cobertura+Checkstyle+Maven+sonar+Jenkins+…. ca rassure son monde. La raison est très bonne, ca fonctionne, ca a fait ses preuves et la maintenance en est facilité.

Laisser un commentaire