Ich habe 3 Projekte der folgenden Struktur:
%Vor%Welche haben die folgende Beziehung:
%Vor% Ich benutze Apache Ivy, um die Abhängigkeiten für App und Lib zu erhalten. Die Abhängigkeiten werden wie folgt beschrieben:
ivy.xml von Lib :
ivy.xml von App :
ivysettings.xml :
Erwartetes Ergebnis: nach Ausführung von ivy:retrieve , wobei sowohl sublib-1.0.jar als auch lib-1.0.jar in App/lib
Tatsächliches Ergebnis: Nur lib-1.0.jar ist in App/lib vorhanden. Der generierte Efeubericht für App enthält keine Erwähnung von sublib als Abhängigkeit von lib . Nichts ist in Ameisen + Logs während des Builds zu finden.
Hinweis: lib-1.0.jar wird nicht als Fat-Jar erstellt.
Was fehlt mir in dieser Konfiguration?
Aktualisieren
Ich habe etwas nachgedacht, und die einzige Schlussfolgerung, mit der ich gekommen bin, ist, dass dieses Problem tatsächlich eine Fehlkonfiguration ist. Aufgrund der Tatsache, dass transitive Abhängigkeit nicht abgerufen wird, können wir positiv sagen, dass Efeu keine Informationen einer Art hat, wenn er lib auflöst. Und das macht Sinn, weil Lib/dist Ordner irgendwo im Dateisystem sein kann. Die einzige Möglichkeit, Informationen über die transitive Abhängigkeit zu erhalten, wäre das entsprechende ivy.xml irgendwo in der Nähe dieses Jars. Was nicht ist. Dies wird durch die Meldung in den Protokollen [ivy:retrieve] local: no ivy file found for com.test.lib#lib;1.0: using default data leicht bestätigt. Die einzige Möglichkeit, Informationen zu erhalten, sind Cache-Daten in %user%/.ivy/cache . Dort enthalten die generierten [org]-[artifact]-[conf].xml -Dateien die Abhängigkeitsinformationen. Damit ich richtig rate, muss ich den Cache auf App's Auflösungsebene verwenden.
Macht das irgendeinen Sinn oder liege ich wieder falsch?
Ok, das Problem war in der Tat die schlechte Konfiguration und mein Mangel an Verständnis. Hier ist die detaillierte Erklärung, wie es funktioniert. Ich bin nicht wirklich gut mit der Terminologie, also habe ich hier vielleicht ein paar Worte mißbraucht. Schauen wir uns die Projektkonfiguration an und was ist was?
Sublib wird eine Laufzeit Abhängigkeit für Lib sein, die eine Abhängigkeit für die Kompilierung hat guava .
Also müssen wir in SubLibs ivy.xml :
Hier stellen wir durch Deklaration einer runtime -Konfiguration fest, dass diese ivy.xml ein Modul beschreibt, das eine Laufzeit-Zeit-Abhängigkeit ist. Und da Guave keine solche Datei hat, beschreiben wir sie als Standard. Ziemlich Standard hier. Damit andere wissen, dass sublib-1.0.jar tatsächlich eine Abhängigkeit von guava-19.0.jar hat, müssen wir sie in einem Repository veröffentlichen, sodass diese Informationen in Form der Datei ivy-[version].xml neben dem jar vorhanden sind. Ich entschied mich, im Ordner build zu veröffentlichen. Um dies zu tun, muss ivysettings.xml einen Resolver enthalten, der hilft, Dateimuster für die Veröffentlichung und später beim Abrufen zu finden, wenn wir von Lib auflösen.
sublib-resolver ermöglicht es, die entsprechende ivy-[revision].xml zu finden, die Informationen über die Abhängigkeiten und die Position von jar enthält. Während filesystem-resolver unsere guava Abhängigkeit finden wird. Jetzt veröffentlichen wir einfach sublib mit ant , indem wir unseren Resolver aufrufen:
Jetzt zu Lib . Lib ist eine Kompilierzeit Abhängigkeit für App und wir beschreiben sie als solche in ivy.xml und deklarieren SubLib als Laufzeitabhängigkeit dafür:
Hier kommt die Konfiguration ins Spiel und was ich zuerst nicht verstanden habe. runtime->compile Die linke Seite ist verständlich: sublib wurde als Laufzeitabhängigkeit deklariert und wir haben sie in ihrer Efeudatei runtime conf zugewiesen. Auf der rechten Seite des Pfeils geben wir an, dass wir auch die Abhängigkeiten von sublib für die Kompilierung benötigen. Und die, die als solche konfiguriert wurde, ist guava . Es wird vom Resolver gefunden und ebenfalls abgerufen. Also brauchen wir auch einen Resolver für Lib , also wird die komplette ivysettings.xml Datei wie folgt aussehen:
Und veröffentlichen von Lib in Lib s build.xml :
Nun zum Hauptproblem: transitives Retrieval. Konfigurationen. In App 's ivy.xml müssen wir genau angeben, dass wir transitive Abhängigkeiten haben wollen. Die Information, dass sie in Repos gespeichert sind, ist nicht genug. Man muss es in App s ivy.xml angeben:
%Vor%
Was hier passiert ist folgendes: Indem wir compile conf deklarieren, geben wir an, dass App eine Kompilierkonfiguration hat. Die erste Pfeilkette gibt, wie zuvor, an, dass wir (kompilierungskonfiguriertes Modul App ) die kompilierkonfigurierte Abhängigkeit namens lib erhalten möchten. Linke und rechte Pfeilseite jeweils. Und der zweite Pfeilsatz besagt, dass wir (compile-configured modul App ) Runtime-konfigurierte Abhängigkeiten von lib erhalten wollen! Was ist sublib . Und da es mit guava zusammenkommt, wird es ebenfalls abgerufen.
Eine kleine unordentliche Erklärung, und vielleicht nicht die eleganteste für eine Lösung, aber es ist die einzige Art und Weise, wie ich es geschafft habe, das überhaupt richtig zu machen. Wenn jemand bessere Möglichkeiten dafür kennt, wird jede Hilfe geschätzt.
Tags und Links java ant dependency-management ivy