Styles

vendredi 1 juillet 2011

Apache Ant/Ivy versus Maven : Quel outil de construction maîtriser sur le long terme ?

Un projet démarre toujours un peu dans l'euphorie, et bien souvent dans le stress dès la première minute où vous vous rendez compte que vous êtes en retard sur les échéances dès la réunion de lancement du projet avec votre client.

Dans ces conditions, il est déjà intéressant d'avoir dès le début du projet, un squelette d'application "vide" mais "fonctionnant", du code et tout son outillage (son attirail) s'exécutant sans aucune fonctionnalité particulière.

On veut tous passer du temps à ajouter des fonctionnalité à un logiciel, pas perdre son temps à mettre en place une architecture standardisée comme Oracle Java EE par exemple. L'avantage d'un tel standard est de proposer des briques et des protocoles standards pour la plupart des applications d'entreprise : une couche présentation (JSF, Struts), une couche métier (EJB3), une couche de persistance (JPA2), des modèles de conceptions tout prêt à être utilisés (Java blueprints), etc.

Ce qui fait que pour la plupart des applications d'entreprise, c'est à dire de gestion de l'information, il n'y a même plus à concevoir quoique ce soit : il ne reste plus qu'à programmer les règles métier et le fonctionnel. Il s'agit d'ailleurs de plus en plus de "configuration" ou de "génération" des composants standards et outils "sur étagère" plutôt que de "programmation" proprement dite.

C'est à la fois une bonne chose (la réutilisation se généralise) et une moins bonne chose pour l’ingénieur en informatique: la conception devient un art mineur et rare dans le monde de l'entreprise. Ce qui a pour conséquence d'offrir de plus en plus de travail à des techniciens et analystes métiers, plutôt qu'à des ingénieurs. Architecte Java ne veut maintenant plus rien dire si ce n'est pour désigner quelqu'un qui connait l'architecture standard Java et sait la mettre en place. Ce n'est plus quelqu'un qui conçoit, mais quelqu'un qui applique. Un architecte logiciel à proprement parlé n'est et ne doit pas être lié à des standards : il doit être capable de définir l'architecture adéquat à un besoin donné en respectant toutes les contraintes qualités qu'on est en droit d'attendre aujourd'hui d'une application logicielle.

Dans ce contexte, il est important de maîtriser à fond quelques outils qui seront présents quelque soit le type de logiciel. Il s’agit de tous les outils de développement : EDI, outils de construction, outils d’analyse de la qualité du code, outils de tests du code, outils de gestion des versions, d’intégration continue. Il est intéressant de passer du temps à maîtriser complètement ces outils, car ils ne seront pas remis en cause dans une dizaine d’année.

Pour ma part, dans le monde Java, je me suis concentré sur les outils suivants : Apache Ant et Ivy, JUnit, Checkstyle, PMD, Jenkins et les bibliothèques standards de la version Java SE.

De plus, j’essaie de maîtriser complètement mon EDI préféré : Emacs.

Par contre, même des technologies dites standards, ne le seront plus au bout de 5 ans, comme par exemple les technologies suivantes qui sont devenus obsolètes :

- toute la couche client de Java SE (AWT, Swing, Java Sound, Java2D, Applets, ImageIO, Accessibility) est maintenant remplacée par JavaFX 2.

- toutes les vieilles couches serveur sont obsolètes : EJB 1 et 2 remplacées par EJB3, les anciennes version d’hibernate remplacées par JPA, même Spring devient obsolète face à JSR-330 (supporté par Spring après coup via des astuces) et de nouveaux frameworks qui suivent cette nouvelle norme comme par exemple Google Guice.

Et bien sur, tout ça sera à revoir dans 5 à 10 ans. Ce qui fait tout drôle aux nouveaux venus dans le monde de l’entreprise informatique, c’est qu’ils vont être confronté à de nombreuses applications qui n’auront même pas franchi le gouffre entre Java 1.4 et Java 5. De nombreuses applications Java peuvent maintenant être appelées des « application legacy » au même titre que des applications codées en Cobol.

Il faut donc s'attendre à tout et maîtriser des outils suffisamment souples, extensibles et personnalisables pour s'adapter à tout type de situation. Ce qui ne va pas dans le sens des outils qui se basent surtout sur des "conventions" plutôt que sur de la configuration, comme par exemple Maven qui structure déjà un projet Java.

Dès que vous sortez de la convention et du comportement standard des plugin Maven, vous allez devoir hacker un plugin Maven pour vous adapter à votre contexte projet. Maven est intéressant pour démarrer un projet rapidement mais dès qu'un projet se complexifie, il y aura toujours des tâches très spécifiques et "tordues" à accomplir. C'est le propre d'un projet qui a son identité propre : si ce n'était pas le cas, ce ne serait pas un projet de développement, mais uniquement un projet de génération de code ou d'installation de composants sur étagère.

Mon vécu sur les outils Ant/Ivy et Maven m'a appris que Ant, par sa simplicité, sa personnalisation, son extensibilité et sa simplicité permet de survivre à des projets complexes et historiquement chargés. Maven, (considéré par certains comme l'EJB2 des outils de construction) permet de démarrer rapidement des projets complets sans avoir à se poser trop de questions sur comment est construit réellement le logiciel. Mais avec le temps qui passe, on est toujours confronté à ces questions précises sur ce qui se passe réellement en arrière plan, et comment changer ces détails.

Bref, Maven me semble aller dans le sens inverse du principe KISS. De plus Ant/Ivy est aussi "puissant" et générique qu'on le souhaite si on passe ne serait-ce que le temps d'un seul livre, à apprendre ce qu'il est capable de faire :

Ant In Action est un bon livre sur Apache Ant/Ivy et va jusqu'au bout de la logique de Ant pour montrer qu'on peut tout faire avec et ce en faisant un minimum d'adhérence aux spécificités d'un projet. J'ai adoré construire de bout en bout un fichier build très simple mais très puissant et surtout très lisible : je suis capable de faire tous les types de traitement que je souhaite et réutiliser mon fichier build.xml dans chacun de mes projets.

Aucun commentaire: