Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide
Consultez :
  • Les documents de reference sur le projet original
  • Les sources de la traduction fr sur GitHub
  • maven


    1.3. Une Interface Commune

    Avant que Maven ne fournisse une interface commune pour construire un logiciel, chaque projet avait une personne dédiée pour gérer son système de build complètement personnalisé. Les développeurs devaient prendre du temps sur leurs développements pour apprendre les arcanes de chaque nouveau projet auquel ils voulaient contribuer. En 2001, vous aviez une approche très différente pour construire un projet comme Turbine par rapport à un projet comme Tomcat. Si un nouvel outil d'analyse statique du code source sortait, ou si un nouveau framework de tests unitaires était développé, tout le monde devrait s'arrêter de développer et voir comment l'intégrer dans l'environnement de build spécifique à chaque projet. Comment exécuter les tests unitaires ? Il existait des milliers de réponses à cette question. Cette époque se caractérisait par des discussions sans fin sur les outils et les procédures pour construire un logiciel. Le monde d'avant Maven était un monde inefficace, l'âge de "l'Ingénieur du Build".

    Aujourd'hui, la plupart des développeurs du libre ont utilisé ou utilisent Maven pour gérer leurs nouveaux projets logiciels. Cette transition n'est pas le simple passage d'un outil de build à un autre, mais l'adoption d'une interface commune de construction de projet. Pendant que les logiciels devenaient modulaires, les systèmes de build devenaient de plus en plus complexes et le nombre de projets a crevé le plafond. Avant Maven, lorsque vous vouliez récupérer le code source de projets comme Apache ActiveMQ ou Apache ServiceMix depuis Subversion et le construire à partir de ses sources, vous deviez passer plus d'une heure à essayer de comprendre comment fonctionnait le système de build de chacun de ces projets. De quoi a t'on besoin pour construire ce projet ? Quelles bibliothèques dois-je télécharger ? Ensuite, où dois-je les mettre ? Quelles tâches dois-je exécuter dans le build ? Dans le meilleur des cas, il fallait quelques minutes pour comprendre comment construire un logiciel, dans le pire (par exemple l'antique implémentation de l'API Servlet du projet Jakarta), construire le logiciel était si complexe qu'il fallait plusieurs heures à un nouveau contributeur pour pouvoir modifier le code source et compiler le projet. De nos jours, il suffit de récupérer le source et d'exécuter la commande mvn install.

    Même si Maven fournit tout un ensemble d'avantages, dont la gestion des dépendances et la réutilisation de comportements communs de build par ses plugins, la raison principale de son succès vient de la création d'une interface unifiée pour construire un logiciel. Si vous voyez qu'un projet comme Apache Wicket utilise Maven, vous pouvez supposer qu'après avoir récupéré son code source, la commande mvn install vous permettra de le construire sans trop de problèmes. Vous savez où insérer la clef de contact, que la pédale d'accélérateur se trouve à droite et le frein à gauche.