Ich habe mich gefragt, wie ich die Abhängigkeiten von Projekten am besten von Ant aus verwalten kann. Was sind die Vor- und Nachteile der Maven Ant Aufgabe und von Ivy?
Antworten
Zu viele Anzeigen?Ich denke, dieser Blogbeitrag deckt genau das ab, wonach der Auftraggeber sucht:
Warum Sie die Maven Ant Tasks anstelle von Maven oder Ivy verwenden sollten
Ivy+Ant ist viel, viel flexibler. Ivy macht Abhängigkeitsmanagement, Punkt, und es macht das extrem gut, besser als Maven. Und mit Ant können Sie so ziemlich jedes Build-System zusammenstellen, das Sie wollen.
Maven versucht alles zu kontrollieren - den "Lebenszyklus" (kompilieren, testen, verpacken, etc.), wo Dateien liegen sollen, und so weiter. Viel Spaß beim Anpassen von Plugins und dergleichen, wenn Ihnen der "Maven-Weg" nicht gefällt.
Maven ist die Antwort auf eine Frage, die niemand gestellt hat. Ein Ant-Skript zu schreiben ist nicht schwer, und Ivy bietet ein besseres Abhängigkeitsmanagement als Maven. Ich bin verwirrt von einigen der vorherigen Kommentare, die behaupten, sie könnten Ivy nicht zum Laufen bringen. Ivy ist viel einfacher als Maven, um es zum Laufen zu bringen.
Das Spring Framework verwendet Ivy in seinem Build-Prozess. Ich denke, das kann als ein Vertrauensbeweis für Ivy angesehen werden.
Wenn es Ihr langfristiges Ziel ist, auf die Verwendung von Maven zur Verwaltung des gesamten Build-Prozesses umzusteigen (was bei neuen Projekten auf der grünen Wiese der Fall sein könnte), dann empfehle ich von ganzem Herzen die Verwendung von Maven pom.xml-Dateien zur Verwaltung von Abhängigkeiten im Namen von Ant build.xml-Dateien. Das Endergebnis ist, dass sowohl Ihre Greenfield-Projekte als auch Ihre Legacy-Projekte den gleichen Mechanismus zur Verwaltung von Abhängigkeiten verwenden. Und es stellt sich heraus, dass Maven wirklich einen besseren Job bei der Verwaltung von Abhängigkeiten für Ant build.xml-Dateien macht als Ivy.
Bevor wir Maven als unser Flaggschiff-Build-Tool einführten, hatte ich einen Entwickler, der versuchte, Ivy in Kombination mit bestehenden Ant build.xml-Dateien zu verwenden. Dies war eine äußerst frustrierende Erfahrung, die uns sehr bald dazu brachte, Ivy abzulehnen. Wir gingen mit der Einführung von Maven voran. Unsere Projekte auf der grünen Wiese wurden nun mit dem Maven-Bestandskonzept erstellt usw.
Ich kehrte jedoch zu den Ant-Legacy-Projekten zurück und begann, den Maven Ant-Task zu verwenden, um Klassenpfaddefinitionen (und gelegentlich andere Ant-Eigenschaftsdefinitionen, die aus der pom.xml gezogen werden) zu definieren. Dies erwies sich als eine Erfahrung der Superlative. Die bestehenden Ant build.xml-Dateien mussten nur leicht modifiziert werden, um die Maven Ant-Integration zu nutzen, um alle Klassenpfade zu definieren, die in der build.xml-Datei verwendet wurden. Alle für das Projekt erforderlichen Abhängigkeiten wurden in einer begleitenden pom.xml-Datei definiert, die von Maven über die in die build.xml-Dateien integrierte Ant-Aufgabe verarbeitet wird.
Maven Scopes können zur Feinabstimmung von Klassenpfad-Definitionen verwendet werden, so dass ein geeigneter Klassenpfad für die Kompilierung, die Ausführung von Unit-Tests, die Paketierung, etc. festgelegt werden kann. Außerdem kann so ziemlich jedes Element, das in der pom.xml-Datei definiert ist, als Ant-Eigenschaft in der build.xml-Datei referenziert werden.
Mit dem Ant-Task für Maven gibt es eigentlich keinen vernünftigen Grund für Ivy, überhaupt zu existieren.
Ich habe gerade 2 Tage damit verbracht, die Ivy-Dokumentation durchzulesen, und ich muss sagen: VERWENDEN Sie MAVEN, wenn Sie überhaupt eine Wahl haben. Ivy ist komplett und völlig Müll, soweit ich sagen kann. Ich habe gerade 2 Tage mit dem Versuch vergeudet, es in meinen Build einzubauen, und gebe es jetzt auf. Und warum?
- Ivy ist ein halbherziger Versuch des Abhängigkeitsmanagements
- Die Ivy-Dokumentation ist ein totaler Witz
- Ivy-Beispiele und Tutorial sind nutzlos
Sobald ich 'Konfigurationen' (sprich: Maven-Profile) eingeführt habe, fing Ivy an, durchzudrehen und alle möglichen Dinge herunterzuladen, die ich nicht brauche, und scheiterte dann. Die Dokumentation für Ivy ist ein absoluter Witz. Im Vergleich dazu liest sich die Maven-Dokumentation wie ein Traum. Wenn Sie ein Beispiel dafür suchen, wie undurchschaubar und schlecht geschrieben die Ivy-Dokumentation ist, werfen Sie einen Blick auf die Referenzseite für Konfigurationen . Sie sind ein wesentlicher Bestandteil eines jeden Gebäudes, aber bei Ivy scheinen sie ein schlecht durchdachtes Zusatzprodukt zu sein.