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

Comparer Maven à ivy/ant revient à comparer un smartphone à la télégraphie.

Si vous voulez tirer parti d'un effet durable dans votre infrastructure de construction, il est préférable d'utiliser Maven car il anticipe et abstrait tous les processus et toutes les tâches auxquels chaque projet de logiciel ou autre projet de type logiciel est confronté. J'ai participé à de nombreux projets et si vos projets deviennent plus complexes, plus divers et plus hétérogènes, vous louerez encore plus la simplicité d'une configuration de projet Maven. En effet, il deviendra complexe mais pas compliqué comparé aux projets pilotés par ivy/ant-driven.

Le principal avantage de Maven est la "convention sur la configuration" (http://en.wikipedia.org/wiki/Convention\_over\_configuration), un paradigme très important. En bref, cela signifie que vous n'avez pas besoin de connaître/configurer des choses qui sont évidentes/triviales/communes. Bien que Maven et tous ses plugins soient livrés avec de nombreux paramètres par défaut, vous avez toujours la possibilité de configurer vos projets en fonction de vos besoins spécifiques. Avec Maven, d'une part, vous pouvez configurer un projet très facilement et rapidement ; d'autre part, vous pouvez personnaliser un projet en cours de développement en fonction de vos besoins avec un minimum d'efforts. Si vous avez compris les concepts clés de Maven, vous tirerez parti de chaque projet, y compris des projets qui ne sont pas des projets de développement de logiciels typiques.

Dans le passé, j'ai écrit beaucoup de ant scripts et avec le prochain Maven j'ai commencé à détester ant. Un inconvénient est que vous copiez toujours scripts et vous répétez, développer des tâches ant qui ne répètent pas des tâches qui ne répètent pas des tâches qui ne répètent pas.... Et le principal inconvénient est que la croissance des scripts de fourmi a tendance à devenir non maintenable, surtout si une douzaine de geeks de fourmi veulent pimper les scripts de chacun.

Beaucoup d'enthousiastes de la fourmi souffrent d'obtenir un contrôle global sur des choses triviales comme la copie d'artefacts et l'impression de messages de construction. Mais comme le concept clé de Maven est de cacher ces choses triviales, la légende restera toujours vivante que Maven restreint les besoins de personnalisation. Mais ne vous inquiétez pas, c'est une légende ! Vous comprenez donc enfin ma déclaration initiale : ne vous occupez pas de choses triviales qui sont déjà résolues.

Peut-être que ivy/ant est une option pour les projets simples, mais pour les projets complexes en croissance, vous avez besoin de simplicité et de conventions. Sinon, vous serez submergé par des problèmes de maintenance de plus en plus nombreux. Surtout si vous avez beaucoup de projets dépendants, de technologies et de parties de produits hétérogènes dans un projet global, vous n'avez pas le temps et l'argent pour développer et tester les ant scripts ou résoudre les problèmes de dépendance.

Un autre conseil doit être mentionné : Ant offre l'intégration de Maven. Cette intégration est souvent utilisée pour tester et jouer avec Maven dans des projets qui ont été développés avec Ant. Évitez cette approche stupide car elle génère plus de problèmes. Au lieu de cela, restez avec ant et sa douleur ou migrez complètement vers maven.

Si vous avez des doutes sur les coûts de migration, je vous suggère d'utiliser la manière contraire d'intégrer ces différents mondes par le Maven-Ant-Plugin. Avec ce plugin standard vous pouvez exécuter chaque ant-script sans aucun effort. Bien sûr, c'est une solution héritée pour un certain temps, mais cela vous donne autant de temps que vous avez besoin pour comprendre les méga-lignes de ant script monstrueux, déformés et non-commentés de votre prédécesseur.

Et maintenant vous allez louer le prochain avantage de maven : Vous avez besoin de très peu de documentation de votre configuration, parce que la documentation fait partie de chaque maven-plugin que vous voulez utiliser.

Donc j'avoue que j'étais un Maven-Antagonist.

Answer 2

Je sais que l'un des avantages d'Ivy est qu'il peut utiliser différents types de dépôts. Maven est généralement très rigide quant au format du dépôt qu'il utilisera. C'est tout ce que je sais.

Answer 3

Je viens de passer 2 jours à lire la documentation d'Ivy et je dois dire, UTILISEZ MAVEN si vous avez le choix. Ivy est une ordure complète et totale pour autant que je puisse dire. Je viens de perdre 2 jours à essayer de l'incorporer dans ma construction et je réduis mes pertes maintenant. Pourquoi ?

• Ivy est une tentative peu convaincante de gestion des dépendances.
• La documentation d'Ivy est une vraie blague
• Les exemples et le tutoriel Ivy sont inutiles

Dès que j'ai introduit les "configurations" (lire les profils maven), Ivy a commencé à se déchaîner en téléchargeant toutes sortes de choses dont je n'ai pas besoin et en échouant. La documentation d'Ivy est une véritable blague. En comparaison, la documentation de Maven se lit comme un rêve. Si vous voulez un exemple de la façon dont la documentation d'Ivy est impénétrable et mal écrite, jetez un coup d'oeil à la page de référence de configurations . Ils constituent une partie essentielle de toute construction, mais dans le cas d'Ivy, ils semblent avoir été mal conçus après coup.