Maven ou Ivy pour gérer les dépendances à partir de Ant ?

Question

Je m'interrogeais sur la meilleure façon de gérer les dépendances des projets à partir d'ant. Quels sont les avantages et les inconvénients de la tâche Ant de Maven et d'Ivy ?

Answer 1

Puisque ce que vous voulez faire est d'ajouter la gestion des dépendances à un projet Ant existant, c'est précisément ce que Ivy est conçu pour faire. La gestion des dépendances est une partie importante de Maven, mais loin d'être la seule. Maven est plus un outil orienté projet qui fait plusieurs autres choses en plus des dépendances. Cela vaudrait la peine de l'envisager si vous prévoyez de migrer vers Maven et d'utiliser également d'autres fonctionnalités de Maven, mais c'est un peu trop si vous ne l'utilisez que pour essaimer Ant.

Votre type de dépendances et vos attentes quant à leur comportement feront également une différence. L'extraction de dépendances tierces est presque triviale dans Maven, tandis qu'Ivy excelle dans la reconstruction de vos propres composants dépendants. Dans un cas comme dans l'autre, les outils ne fourniront pas une construction, un versionnement et un dépôt décents. politiques Ces éléments sont toujours à votre charge et sont nécessaires pour obtenir la bonne configuration.

Answer 2

Ant + Ivy == Un terrain de camping, où les gens utilisent les installations selon leurs besoins.
Maven == Un centre de villégiature, où vous comptez sur quelqu'un d'autre pour vous fournir des services.

Maven est plus facile pour une équipe manquant d'expérience dans le domaine de la construction et de l'intégration, mais lorsque l'équipe doit s'écarter des normes de Maven, elle se retrouve à chercher du côté de groovy ou de gradle, et le manque de documentation solide devient frustrant.

Ant + Ivy prendront plus de temps pour démarrer un projet, mais si l'équipe a de l'expérience en matière de construction/intégration, elle peut adapter le système de construction à la façon dont elle développe et publie le code.

Dans les sociétés d'ingénierie... de technologie, j'insiste toujours sur la solution du camping plutôt que sur celle du centre de villégiature.

Il est cependant étonnant que Ant et Maven choisissent tous deux XML comme langage pour exprimer les recettes de construction. La communauté Java est bloquée sur ce XML...

Answer 3

Ivy+Ant est beaucoup, beaucoup plus flexible. Ivy gère les dépendances, point final, et il le fait extrêmement bien, mieux que Maven. Et avec Ant, vous pouvez pratiquement mettre en place le système de construction que vous voulez.

Maven essaie de tout contrôler - le "cycle de vie" (compiler, tester, empaqueter, etc.), l'emplacement des fichiers, etc. Amusez-vous à personnaliser les plugins et autres si vous n'aimez pas la "méthode Maven".

Maven est la réponse à une question que personne n'a posée. Ecrire un Ant script n'est pas difficile, et Ivy vous donne une meilleure gestion des dépendances que Maven. Je suis confus par certains des commentaires précédents affirmant qu'ils n'ont pas réussi à faire fonctionner Ivy. Ivy est beaucoup plus simple à mettre en place que Maven.

Le Spring Framework utilise Ivy dans son processus de construction. Je pense que cela peut être considéré comme un vote de confiance pour Ivy.

Answer 4

Si votre objectif à long terme est de migrer vers l'utilisation de Maven pour gérer l'ensemble du processus de construction (ce que l'on pourrait avoir l'intention de faire pour les nouveaux projets greenfield), alors je recommande vivement d'utiliser les fichiers pom.xml de Maven pour gérer les dépendances au nom des fichiers build.xml de Ant. Le résultat final est que vos nouveaux projets et vos anciens projets utilisent tous le même mécanisme pour gérer les dépendances. Et il s'avère que Maven fait vraiment un meilleur travail de gestion des dépendances pour les fichiers Ant build.xml que Ivy.

Avant d'adopter Maven comme notre outil de construction phare, j'ai eu un développeur qui a essayé d'utiliser Ivy en combinaison avec des fichiers build.xml Ant existants. Ce fut une expérience des plus frustrantes qui nous a très vite conduits à rejeter Ivy. Nous sommes allés de l'avant avec l'adoption de Maven. Nos nouveaux projets ont commencé à être construits avec l'approche Maven standard, etc.

Cependant, je suis retourné aux anciens projets Ant et j'ai commencé à utiliser la tâche Ant de Maven pour définir les définitions de classpath (et occasionnellement d'autres définitions de propriétés Ant tirées du pom.xml). Cela s'est avéré être une expérience des plus agréables. Les fichiers build.xml existants de Ant n'ont dû être que légèrement modifiés pour utiliser l'intégration de Maven Ant afin de définir tout classpath utilisé dans le fichier build.xml. Toutes les dépendances requises par le projet ont été définies dans un fichier pom.xml d'accompagnement qui est traité par Maven via la tâche Ant incorporée dans les fichiers build.xml.

Les scopes Maven peuvent être utilisés pour affiner les définitions de classpath de manière à établir une définition adaptée à la compilation, ou à l'exécution de tests unitaires, ou à l'empaquetage, etc. De plus, pratiquement tous les éléments définis dans le fichier pom.xml peuvent être référencés en tant que propriété Ant dans le fichier build.xml.

Vraiment avec la tâche Ant pour Maven il n'y a aucune raison viable pour Ivy d'exister.

Answer 5

Je pense que cet article de blog couvre exactement ce que le PO recherche :

Pourquoi vous devriez utiliser les tâches Maven Ant au lieu de Maven ou Ivy