Pourquoi Apache dispose-t-il de deux outils distincts pour la gestion des builds et des dépendances?


9

Apache dispose de deux outils distincts:

Ils semblent tous deux occuper le même créneau. J'ai deux questions:

  1. Quels sont les points saillants des principales différences entre les deux outils?
    • Je suis sûr qu'un très long article pourrait être écrit sur les différences entre les deux, je ne recherche pas autant de détails, ni un argument subjectif pour choisir l'un plutôt que l'autre.
  2. Histoire de la programmation - comment est-il arrivé qu'Apache ait évolué pour créer deux ensembles d'outils complètement distincts qui sont finalement si similaires dans leur objectif?

Réponses:


7

Quels sont les points saillants des principales différences entre les deux outils?

  • Structure du projet

    • Maven préfère une structure de projet spécifique: il faut s'engager à faire les choses à la manière du Maven. Maven est livré avec des étapes de construction communes déjà configurées dans une racine pom.xmlqui est normalement héritée par tous les autres projets pom.xml.

    • Ant + Ivy est plus ouvert: bien qu'il puisse faire beaucoup, il n'y a que quelques exigences de base en termes de structure de projet ou d'utilisation de script. Il n'y a pas de tâches, d'objectifs ou de processus de construction prédéterminés. Chacun build.xmlest une table rase (à moins d'inclure un autre script, bien sûr).

  • Orientation

    • Maven est orienté objectif . Vous ne dites pas «exécuter cette cible de construction», vous lui demandez de «construire» ou de «déployer» et Maven fait tout ce qu'il doit faire pour y arriver: vous dites ce que vous voulez faire.

    • Ant + Ivy est orienté tâche . Chaque tâche est définie par l'implémentation et personnalisée. Vous lui dites comment faire ce que vous voulez.

  • Gestion des dépendances

    • Maven est surtout connu pour gérer automatiquement les dépendances. Il téléchargera les versions correctes lors de la construction sans aucune intervention de l'utilisateur tant que les URL du référentiel sont correctement configurées à l'avance.

    • Ant n'a pas de gestion des dépendances à l'exception de "Java Classpath". Ivy ajoute une gestion des dépendances un peu plus fastidieuse que Maven mais toujours automatisée. La clé ici est que vous ne pouvez pas choisir de gestion des dépendances (par exemple, "les pots inclus dans ma distribution ou vérifiés dans le contrôle de source") ou vous pouvez l'externaliser via Ivy. Ce choix signifie plus de flexibilité pour répondre aux besoins du projet.

  • Facilité d'utilisation

    • Maven est (en théorie) facile à utiliser. Tout développeur peut prendre un projet Maven et savoir immédiatement où se trouvent toutes les ressources du projet et à quoi elles servent: cela est dû au premier point sur Maven ayant une manière spécifique de faire les choses.

    • Ant + Ivy peut avoir une courbe d'apprentissage plus abrupte car chaque projet peut être différent. Différents projets peuvent avoir différentes manières d'atteindre les mêmes objectifs.

  • Extensibilité

    • Maven permet d'écrire des plugins et de modifier son processus de construction. Cependant, il sort de la boîte avec une racine pom.xmlqui pousse les développeurs vers ses processus de construction prédéterminés. De nouveaux objectifs ou étapes de génération nécessitent une réflexion approfondie et des efforts supplémentaires pour être injectés dans le processus de génération.

    • Ant + Ivy permet également d'écrire des plugins et de nouvelles tâches: cela est assez facile et on peut intégrer une nouvelle tâche avec un minimum d'effort. Il n'y a pas d'objectifs ou de cibles prédéterminés à parcourir ou à intégrer sa nouvelle tâche.

Comment est-il arrivé qu'Apache ait évolué pour créer deux ensembles d'outils complètement séparés qui sont finalement si similaires dans leur objectif?

La première chose à comprendre est que le projet Apache n'est rien d'autre qu'un parapluie sous lequel opèrent des projets séparés et indépendants. Différentes équipes travaillent sur différents projets. Bien que les développeurs individuels puissent travailler sur plusieurs projets, il n'y a pas de feuille de route globale qui intègre Ant, Ivy et Maven.

Ant est venu en premier. Il a été conçu pour être un équivalent Java de Make. Alors que Make peut construire des projets Java, il est fastidieux: Make existait pour compiler un tas d'unités de compilation séparément puis les lier. La méthode Java consiste à javactout compiler en une seule fois, et ce que nous appelons la "liaison" se produit vraiment dans les tripes de la JVM au moment de l'exécution. Make n'était pas le bon outil pour le travail: un Makefile pour Java est essentiellement une ou deux cibles ( javac, jar).

Ant a ajouté un peu de structure au-dessus de Make, mais n'a pas fondamentalement modifié le processus.

Après un certain temps, la communauté s'est rendu compte que la chasse aux fichiers jar n'était pas amusante. De plus, il n'y avait pas de méthode standard pour composer des projets. Sans cohérence, le développement Java était un gâchis. Maven a été conçu pour résoudre ces problèmes: il apporterait une structure de projet commune et automatiserait la recherche des fichiers jar.

Cependant, Ant était toujours vraiment utile. Certains projets se prêtent simplement davantage à la nature ad hoc des processus de Ant. Certains projets ne compilent pas de code. Certains projets étaient anciens et il était peu probable que quiconque les «mette à niveau» vers Maven.

Ivy arrive: il ajoute la gestion des dépendances à Ant, donnant aux projets le meilleur des deux mondes. Vous pouvez conserver vos scripts hérités, ou votre environnement hautement personnalisé, mais bénéficiez de la fonctionnalité la plus importante de Maven: la gestion des dépendances.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.