07 octobre 2011

Maven WishList

Certains sont surpris de voir que j'ai écrit un livre sur Maven et qu'en même temps je le critique. Et oui, je ne suis pas un évangéliste tout blanc tout noir, pour moi Maven a apporté des choses très positives mais n'est pas l'outil parfait, loin s'en faut.

Les points principaux apportés par Maven sont (ahma) :

  • la standardisation de la structure des projets, rappelez vous le plaisir de greffer des morceau de build Ant d'un projet à l'autre ...
  • le concept de dépôt de bibliothèques et de gestion des dépendances, avec la construction progressive de central, aujourd'hui incontournable,
  • le mécanisme de plugins pour enrichir un build, avec une isolation des plugins (ce que ne faisait pas maven 1)
Mais ... Maven c'est aussi des points qui me déplaisent :

Le cycle de vie est extrêmement rigide et très, très compliqué à modifier (nécessite un nouveau packaging). Or il m'est souvent arrivé de regretter qu'il manque une phase pour y greffer un plugin, ce qui aboutit souvent à déclarer le plugin sur une phase inadaptée comme contournement. Exemple type : le compresseur JavaScript placé en phase "test" pour que le war soit construit avec des scripts optimisés (depuis est arrivé prepare-package, mais vous avez l'idée générale). On en arrive à hacker l'ordre d'exécution des plugins pour obtenir ce qu'on désire.

Le déploiement n'est pas atomique, loin s'en faut. C'est même pire que ça, il a lieu de manière morcelée lors d'un build multi-module. Si ça plante au milieu, une partie des artefacts est déjà déployée. Les connaisseurs auront reconnu le rôle tenu par le RedeployPublisher de Jenkins ... Alors bien sûr, Nexus pro comme Artifactory (peut être même Achiva ;P) proposent des solutions de contournement. On compense une défaillance de l'outil par un autre outil.

La gestion "one-shot" des métadonnées. Combien de bibliothèque ont été publiées avec un POM tout pourri ? Si les choses ont un peu progressé, il aurait été plus efficace d'avoir un mécanisme de version sur ces méta-données, en plus de la version de l'artefact, quitte à figer cette version lors de la release. De ce point de vue, héberger un repo maven sous forme de dépôt svn n'aurait pas été idiot, et lors de la release on aurait juste indiqué qu'on fait référence au méta-données du dépôt @révision1234.

Le POM sert à la fois de méta-données et de support du build. Combien de POM déployés contiennent des profils, des paramètres liés au développement ou aux environnements de test. A cumuler ces deux rôles, le POM se tire une balle dans le pied. Il faudrait découpler le build (profils, plugins, etc) des méta-données (dépendances, license, pré-requis, ...)

L'identification du dépôt d'un artefact. Si aujourd'hui je dépends de Hibrenate 4, que j'obtiens depuis le dépôt jBoss, dans 6 mois en voulant reconstruire mon projet, peut être aura t-il été publié sur central, ou sur l'un des (nombreux ?) autres repos que je déclare dans mon POM. Qu'est ce qui me garantit que c'est bien le même ? Deux options pour cela :

  • indiquer explicitement, via un attribut supplémentaire sur dependency, le repo d'où je désire obtenir l'artefact, ce qui accessoirement éviterait d'interroger 36 dépôts
  • fournir le hash SHA de l'artefact que je veux utiliser. Ca pourrait d'ailleurs complètement remplacer le groupId:artifactId:version, bien que ce ne serait pas super pratique.


Non, Maven n'est pas la panacée, mais il faut reconnaitre que les alternatives viables ne sont pas légions. Chacun ira de son commentaire sur Gradle, Rake, BuildR, ou truc-chose, si des choses intéressantes sont proposées elles sont très loin d'atteindre la maturité et le support par l'outillage qu'à Maven.

Wait and See ... peut être un jour un petit nouveau dans la cours des grand pour bousculer tout ça ?


  ________              ____   ____                 
 /  _____/_______ _____ \   \ /   / ____    ____    
/   \  ___\_  _ \ \__  \ \   Y   /_/ __ \  /    \   
\    \_\  \|  | \/ / __ \_\     / \  ___/ |   |  \  
 \______  /|__|   (____  / \___/   \___  ]|___|  /  
        \/             \/              \/      \/   
                                                        v 0.0.0.2 



02 octobre 2011

Play Framework Cookbook

Packt a sorti un ouvrage consacré à Play! framework, et me l'a proposé en relecture dans le cadre de la bibliothèque du BreizhJug. Détail amusant, la même bibliothèque est en train de s'outiller d'une application web sur mesure, développé par Sylvain ... en Play!

J'ai donc ouvert ce livre sans rien connaître de Play! en dehors de quelques essais express et de la présentation faite par Guillaume Bort au BreizhJug

Le format  cookbook consiste à découper le livre en cours chapitres qui présentent un objectif et sa mise en oeuvre avec le framework, accompagné de quelques liens ou idées pour aller plus loin. L'avantage de cette formule est qu'on peut rapidement piocher les réponses à un problème qu'on rencontre, par contre l'inconvénient est souvent que le livre est assez peu abordable pour le novice, sautant un peu du coq à l'âne. Et bien, pour cet ouvrage, je salue le talent de l'auteur qui a su ordonner ses recettes et leur donner un niveau de détail progressif qui permet tout aussi bien de lire le livre de manière séquentielle pour découvrir Play! et pratique rapidement l'utilisation du framework sur une application.

Bon bouquin en résumé pour prendre Play! en main, quelque soit votre niveau de connaissance du framework. On pourra juste (?) regretter l'absence de recettes sur l'utilisation de Scala, déjà très bien intégré dans Play! 1.x et qui sera au centre de Play! 2.