Nutzen Sie diese Techniken, um Maven Jar-Paketkonflikte einfach zu lösen

Verfasser: Platinum Poseidon

Ursprünglicher Link: https://www.cnblogs.com/bryan31/p/13408479.html

Vorwort

Jeder muss im Projekt auf Mavens Jar-Paket-Konfliktproblem gestoßen sein. Die häufigsten Szenarien sind:

NoSuchMethodError und ClassNotFoundException werden bei lokaler Ausführung gemeldet. Offensichtlich befindet sich dieses Jar-Paket in der Abhängigkeit. Warum kann es nicht laufen! ?

Das Projekt definiert eine bestimmte JAR-Paketversion eindeutig als 2.0.2. Wie kann sie nach dem Verpacken zu 2.5.0 werden? ?

Das A-Projekt importierte das xxx.jar-Paket und lief gut, und das B-Projekt importierte auch xxx.jar, und es wurde ein Fehler gemeldet. . Gibt es ein Problem mit dem B-Projekt oder dem xxx.jar-Paket! ?

Die lokale Umgebung und die Testumgebung laufen gut. Wenn es um die Produktion geht, werden eine Reihe von NoSuchMethodErrors gemeldet. Gibt es ein Problem mit meinem Charakter oder der Produktionsumgebung? ?

Wenn ein solches Problem von Schülern untersucht wird, die mit dem Maven-Abhängigkeitsmechanismus nicht vertraut sind, treten Kopfschmerzen auf.

Darüber hinaus ist maven auf schlecht strukturierte Projekte angewiesen, und das Risiko, neue Jar-Pakete einzuführen, ist ebenfalls enorm. Kleinere beeinträchtigen die Leistung, während größere Ausnahmen für die Produktionsfreigabe und die Laufzeit verursachen.

Tatsächlich liegen die Hauptursachen für die oben genannten Probleme in Mavens Jar-Paketkonflikt und der missbräuchlichen Verwendung der Abhängigkeitsübermittlung. In diesem Artikel werde ich die folgenden 3 Inhalte analysieren:

• Analyse des Prinzips, sich auf die Lieferung zu verlassen, und des Prinzips, Jar-Paketkonflikte zu verursachen
• Verschiedene einfache Techniken zum Auffinden von Konflikten und zum Lösen von Jar-Paketkonflikten
• So schreiben Sie eine POM-Datei mit sauberen Abhängigkeiten

Prinzip der Abhängigkeitsübertragung

Fast alle Jar-Paketkonflikte hängen mit dem Prinzip der Abhängigkeitsübertragung zusammen. Lassen Sie uns zunächst über das Prinzip der Abhängigkeitsübertragung in Maven sprechen:

Das Prinzip des kürzesten Weges

Wenn zwei Jar-Pakete A und B eingeführt werden, die beide transitiv vom Jar-Paket Z abhängen:

A -> X -> Y -> Z (2,5)

B -> X -> Z (2,0)

Tatsächlich war die Version, die schließlich in Kraft trat, Z (2.0). Weil sein Weg kürzer ist. Wenn ich lokal auf das Z (3.0) -Paket verweise, ist die 3.0-Version wirksam. Der gleiche Grund.

Erklären Sie zunächst das Prioritätsprinzip

Wenn die Pfadlänge gleich ist, wird die zuerst deklarierte bevorzugt.

A -> Z (3,0)

B -> Z (2,5)

Hier ist A das erste, das deklariert, daher wählt das übergebene Z die Verwendung von Version 3.0.

Das Prinzip des Jar-Paketkonflikts

Angenommen, unser Projekt basiert auf zwei Jar-Paketen, A und B. Und A und B haben jeweils die folgenden transitiven Abhängigkeiten

A -> X -> Z (2,0)

B -> X -> Y -> Z (2,5)

Dann kollidiert das Z-Paket im endgültigen System, und die beiden Versionen 2.0 und 2.5 stehen in Konflikt. Es ist jedoch nur eine Version des Z-Pakets vom Klassenpfad abhängig. Nach dem Prinzip des kürzesten Weges der transitiven Abhängigkeit sollte die endgültige Abhängigkeit Version 2.0 sein.

Wenn die neue Methode in der 2.5-Version des Z-Pakets im Y-Paket verwendet wird, wird diese Logik ausgeführt. Meldet NoSuchMethodError. Da es ursprünglich auf Version 2.5 beruhte, Maven jedoch aufgrund des Jar-Paketkonflikts Version 2.0 auswählte und es in Version 2.0 keine neue Methode gab, die einen Fehler verursachte.

Es ist jedoch zu beachten, dass nicht alle Konflikte zu einem abnormalen Betrieb führen. Im Gegenteil, die meisten Projekte des Unternehmens weisen einige Jar-Paketkonflikte auf, die jedoch keine Laufzeitprobleme verursachen.

Dies liegt daran, dass viele Jar-Pakete, die transitiv abhängig sind, unabhängig davon, ob es sich um Version 2.0 oder Version 2.5 handelt, ausgeführt werden können.

Nur die höhere Version des Jar-Pakets ist nicht abwärtskompatibel, oder einige neue APIs, die in der niedrigeren Version nicht verfügbar sind, können dieses Problem verursachen

Positionierungskonflikt

IDEA bietet ein Artefakt zur Analyse der Maven- Abhängigkeit: Maven Helper

 

Verwenden Sie dieses Plugin, um alle Abhängigkeitsbäume und Konflikte im Projekt anzuzeigen.

 

Der hier rot hervorgehobene Teil zeigt an, dass das Jar-Paket einen Konflikt aufweist. Wählen Sie dieses JAR-Paket aus. Sie können die Ursache des Konflikts zwischen den beiden Versionen sehen.

Das Beispiel in der obigen Abbildung zeigt, dass das Jar-Paket von Cruiser-Client zwei transitive Abhängigkeiten aufweist, nämlich Version 2.5.0 und Version 4.0.1. Die Beschreibung des Konflikts lautet:

wegen Konflikts mit 2.5.0 weggelassen. wegen Konflikts mit 2.5.0 weggelassen

Die spezifische Ebene ist auch auf der rechten Seite klar, so dass Maven schließlich Version 2.5.0 basierend auf dem Prinzip des kürzesten Weges zuerst auswählte und Version 4.0.1 ignoriert wurde.

Zu diesem Zeitpunkt werden einige Schüler fragen: Ich kann Maven Helper verwenden, um die lokale Umgebung zu lokalisieren, was ist mit der Vorproduktion oder der Produktionsumgebung. Wie kann man ohne IDEA die Details des Konflikts lokalisieren?

Mit dem Befehl mvn können Sie Folgendes lösen:

MVN-Abhängigkeit: Baum -Dverbose

Lassen Sie den Parameter -Dverbose hier nicht weg, da sonst die ignorierten Pakete nicht angezeigt werden

 

Tatsächlich ist die mvn-Befehlszeile genauso einfach zu bedienen. Sehr deutlich.

Verschiedene praktische Techniken zur Lösung von Jar-Paketkonflikten

Ausschluss

Das obige Beispiel, jetzt 2.5.0, ist immer noch wirksam, wenn Sie 4.0.1 wirksam werden möchten. Klicken Sie einfach auf Ausschließen in 2.5.0.

 

Versionssperre

Wenn viele Abhängigkeiten an Jar-Paket A übergeben werden, sind viele Versionen beteiligt, Sie möchten jedoch nur eine Version angeben. Es ist zu umständlich, einen nach dem anderen durch die Ausschlussmethode auszuschließen, und der Ausschluss wird in der POM-Datei wiedergegeben. Wenn zu viele vorhanden sind, wirkt sich dies auch auf die Sauberkeit des Codes und das Leseerlebnis aus.

Zu diesem Zeitpunkt müssen Sie die Versionssperrmethode verwenden

Was ist Versionssperre? Das Projekt eines Unternehmens hat im Allgemeinen einen übergeordneten POM. Sie müssen nur wie folgt angeben, welche Version Sie im übergeordneten POM Ihres Projekts angeben möchten (dies kann natürlich auch in diesem Projekt definiert werden): (Oder nehmen Sie im vorherigen Beispiel Version 4.0.1 an.)

<dependencyManagement>
    <dependency>
        <groupId>org.apache.curator</groupId>
        <artifactId>curator-client</artifactId>
        <version>4.0.1</version>
    </dependency>
</dependencyManagement>

Die Methode der gesperrten Version kann die beiden Prinzipien der Abhängigkeitsübertragung mit der höchsten Priorität brechen

Nachdem die Version gesperrt wurde, lautet der Abhängigkeitsbaum:

 

Sie sind alle auf 4.0.1 vereinheitlicht. Das Sperren der Version bietet einen Vorteil: Das Sperren der Version schließt das Jar-Paket nicht aus und zeigt alle inkonsistenten Jar-Pakete in einer einheitlichen Version an, die beim Lesen des Codes benutzerfreundlicher ist. Sie müssen nicht viele Ausschluss-Tags ertragen.

So schreiben Sie eine POM-Datei mit sauberen Abhängigkeiten

Ich bin eine Person mit milder Code-Sauberkeit, daher möchten auch die Abhängigkeiten der POM-Datei sauber und ordentlich sein. Wie man ein sauberes POM schreibt, glaubt der Autor, dass es mehrere Tipps gibt, auf die man achten sollte:

• Versuchen Sie, <dependencyManagement> im übergeordneten POM zu definieren, um einige abhängige Versionen dieses Projekts zu verwalten, damit bestimmte Konflikte weitgehend gelöst werden können
• Wenn es sich um ein Jar-Paket handelt, das anderen zur Verfügung gestellt wird, versuchen Sie, nicht so viele unnötige Jar-Pakete wie möglich weiterzugeben
• Verwenden Sie den Befehl mvn dependency: analyse-only, um die deklarierten, aber nicht verwendeten Abhängigkeiten zu ermitteln. Wenn einige von Ihnen selbst deklariert wurden, versuchen Sie, sie zu entfernen
• Verwenden Sie den Befehl mvn dependency: analyse-duplicate, um die wiederholt definierten Abhängigkeiten zu analysieren und diese wiederholt definierten Abhängigkeiten zu bereinigen

Zu guter Letzt

Tatsächlich muss es viele Abhängigkeiten von großen Projekten geben. Aber egal wie kompliziert die Abhängigkeit ist, haben Sie keine Angst, sie zu sehen. Mit nur wenigen Prinzipien und sorgfältiger Analyse sind alle Abhängigkeiten nachvollziehbar.

Wenn diese transitiven Abhängigkeiten gut verwaltet werden, können Ihre Wartungskosten erheblich reduziert werden. Wenn Sie nicht gut zurechtkommen, kann jedes dieser wilden Kinder die Sicherung für den nächsten NoSuchMethodError sein.