Scheiße einen Fehler in einer Bibliotheksabhängigkeit von Drittanbietern

Question

Ich habe einen kleinen Fehler in einem größeren Anwendungsrahmen gefunden, den ich verwende. Das Fixieren erfordert nur zwei Zeilen in einer einzigen Klasse. Ich habe das Problem behoben und die Änderungen in das Repository des Projekts weitergegeben.

Ich muss jedoch morgen veröffentlichen. Daher kann ich es kaum erwarten, bis die Bibliothek eine neue Version veröffentlicht. Ich frage mich, was der beste Weg wäre, um die gepatchte Version in mein Projekt zu integrieren:

• Erstellen Sie das Projekt: Dies fällt mir ziemlich schwierig, ich kann es nicht einmal ordnungsgemäß erstellen, da so viele Unit -Tests im Snapshot -Repository unterbrochen werden. Auch ohne die Einheitstests komme ich nicht sehr weit, da mir offensichtlich einige Abhängigkeiten fehlen, die nicht gefunden werden können in Maven Central. Außerdem muss ich die feste Version an jeden anderen Entwickler senden, da sie nicht in Maven Central gefunden werden kann. (Wir arbeiten im Netz und haben keinen eigenen Nexus.)

• Hinzufügen eines neuen Moduls zu meinem Projekt, in dem ich eine Kopie der Klasse behalte, die ich behoben habe. Ich füge dieses Modul dann allen Modulen als Abhängigkeit hinzu, die die Überschreibungsversion der Klasse verwenden sollten. Aber wie ermittelt die JVM, welche Klasse sie tatsächlich lädt? Es wird zwei finden Krug-Files, die eine Klasse mit demselben Namen enthalten. Welches wird es tatsächlich laden? Wenn ich diese Arbeit machen könnte, würde ich es mir ermöglichen, die geänderte Version der Klasse mit meinem Projekt so zu integrieren, dass ich das Patch zusammen mit dem Projekt verteilen kann und sobald der Fehler repariert wird, kann ich einfach das Modul entfernen.

• Ich füge die geänderte Klassendatei in das betroffene Modul selbst ein. Bisher erscheint dies als die einfachste Lösung für mich, da die JVM die Klasse immer zuerst aus demselben Glas lädt. (Habe ich recht? Zumindest habe ich das in meinen Tests beobachtet.)

Vielen Dank für jede Eingabe dazu.

Answer 1

Am Ende habe ich das Projekt separat erstellt und diese Version in einen anderen Namespace verschoben. Dies ist anscheinend nicht so ungewöhnlich. Zum Beispiel hält Hibernate CGlib in seinem eigenen Namespace, um Versionskonflikte aufgrund von API -Änderungen zu vermeiden.

• Die erste vorgeschlagene Lösung hatte ein Problem, als das von mir verwendete Projekt auch in einer anderen Abhängigkeit verwendet wurde, was dazu führte, dass sowohl meine modifizierte Version als auch die normal Die Version war auf dem Klassenpfad, was zu sehr seltsamem Verhalten führte, da Konflikte benannt wurden.

• Der zweite und dritte Vorschlag hatte ähnliche Probleme wie der erste Vorschlag. Zusätzlich habe ich die Kompatibilität für andere Versionen der Abhängigkeit gebrochen.

Sogar es klingt schmerzhaft: Aus dem Namespace auszuziehen und einen separaten Build zu liefern, ist ein Muss, auch wenn Sie nur ein paar Codezeilen ändern.

Answer 2

Ich denke, die beweglichen Abhängigkeiten Ihres Projekts in benutzerdefinierte Namespaces sind aus mehreren Gründen nicht optimal:

• Ihre Änderungen werden wahrscheinlich nicht an die ursprünglichen Entwickler der Abhängigkeit zurückgeschickt.
• Es wird schwierig sein, mit neuen Abhängigkeitsversionen Schritt zu halten, also keine Fehler mehr, keine neuen Funktionen, keine Sicherheitsbehörden von Entwicklern und Mitwirkenden von Drittanbietern.
• Meine Erfahrung ist, dass es im Laufe der Zeit vergessen wird wie und warum Die benutzerdefinierte Namensabhängigkeit wurde geändert. Dies wird dazu führen, dass dieser Teil des Projekts nicht nur veraltet, sondern auch unantastbar ist, da niemand weiß, was beim Ersetzen brechen wird.

Ich bin damit einverstanden, dass ein Workflow mit Jitpack die beste Lösung ist. Ich schrieb einen Blog -Beitrag mit einem detaillierten Leitfaden für dies mit nur ein paar Minuten Overhead: https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

Answer 3

Tl; dr;

Besuch https://jitpack.io und lesen Sie, wie es funktioniert

---

Schritte zur Lösung des Problems

Angenommen, die Bibliothek von Drittanbietern befindet sich auf Github, klonen Sie einfach das Projekt und beheben Sie es.

Dann benutze https://jitpack.io. Jitpack erstellt einen .jar aus Ihrem Repo (wo Sie den Code behoben haben) und generiert eine Abhängigkeit für Sie wie

<dependency>
    <groupId>GITHUB_USER</groupId>
    <artifactId>REPOSITORY</artifactId>
    <version>COMMIT</version>
</dependency>

Außerdem müssen Sie dieses Remote -Repository explizit hinzufügen

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

• Schnelle Arbeit
• Einfach zu tun
• Einfach rückgängig zu machen