Fixant à chaud un bug dans une dépendance à une bibliothèque tierce

Question

J'ai trouvé un bug mineur dans un cadre d'application plus grand que j'utilise. La fixation nécessite uniquement de modifier deux lignes en une seule classe. J'ai résolu le problème et poussé les modifications au référentiel du projet.

Cependant, j'ai besoin de sortir demain. Par conséquent, je ne peux pas attendre que la bibliothèque publie une nouvelle version. Je me demande quelle serait la meilleure façon d'intégrer la version corrigée dans mon projet:

• Construisez le projet: ce que je trouve assez difficile, je ne peux même pas le construire correctement car tant de tests unitaires sont cassés dans le référentiel instantané et même sans les tests unitaires, je n'obtiens pas très loin car il me manque évidemment des dépendances qui ne peuvent être trouvées à Maven Central. De plus, je dois envoyer la version fixe à tous les autres développeurs car il ne peut être trouvé sur Maven Central. (Nous travaillons sur le net et nous n'avons pas notre propre lien.)

• L'ajout d'un nouveau module à mon projet où je garde une copie de la classe que j'ai corrigée. J'ajoute ensuite ce module en tant que dépendance à tous les modules qui devraient utiliser la version OverRenden de la classe. Mais comment le JVM détermine-t-il quelle classe il charge réellement? Il en trouvera deux pot-Files qui contiennent une classe avec le même nom. Lequel sera-t-il réellement chargé? Si je pouvais faire ce travail, cela me permettrait d'intégrer la version modifiée de la classe avec mon projet de telle sorte que je puisse distribuer le correctif avec le projet et une fois le bug corrigé, je pourrais simplement supprimer le module.

• J'inclus le fichier de classe modifié dans le module affecté lui-même. Jusqu'à présent, cela me apparaît comme la solution la plus simple, car le JVM chargera toujours la classe du même pot en premier. (Ai-je raison? Au moins, c'est ce que j'ai observé dans mes tests.)

Merci pour toute contribution à ce sujet.

Answer 1

J'ai fini par construire le projet séparément et déplacer cette version vers un autre espace de noms. Ce n'est apparemment pas si rare. Par exemple, HiberNate maintient CGLIB dans son propre espace de noms afin d'éviter les conflits de version en raison des modifications de l'API.

• La première solution suggérée a eu un problème lorsque le projet que j'ai utilisé a également été utilisé dans une autre dépendance qui a conduit à la fois à ma version modifiée et à la Ordinaire La version était sur le chemin de la classe ce qui a conduit à un comportement très étrange en raison de conflits de dénomination.

• Les deuxième et troisième suggestions ont eu des problèmes similaires à la première suggestion. De plus, j'ai brisé la compatibilité avec d'autres versions de la dépendance.

Même cela semble douloureux: sortir de l'espace de noms et fournir une version séparée est un must, même si vous ne changez que quelques lignes de code.

Answer 2

Je pense que le déplacement des dépendances de votre projet dans des espaces de noms personnalisés n'est pas optimal, pour plusieurs raisons:

• Vos modifications ne seront probablement pas renvoyées aux développeurs originaux de la dépendance.
• Il sera difficile de suivre de nouvelles versions de dépendance, donc plus de bugfixes, pas de nouvelles fonctionnalités, pas de correctifs de vulnérabilité de développeurs et contributeurs tiers.
• Mon expérience est qu'au fil du temps, il est oublié comment et Pourquoi La dépendance personnalisée a été modifiée. Cela entraînera cette partie du projet non seulement obsolète, mais aussi intouchable, car personne ne saura ce qui va se casser lors du remplacement.

Je suis d'accord qu'un workflow utilisant Jitpack est la meilleure solution. J'ai écrit un article de blog avec un guide détaillé pour le faire avec seulement quelques minutes de frais généraux: https://5am.technology/2016/12/fix-bugs-third-starty-dependency-jitpack/

Answer 3

Tl; dr;

Visite https://jitpack.io Et lisez comment ça marche

---

Étapes pour résoudre le problème

En supposant que la bibliothèque tierce est sur GitHub, clonez simplement le projet et réparez-le.

Puis utiliser https://jitpack.io. Jitpack crée un .jar à partir de votre dépôt (où vous avez corrigé le code) et génère une dépendance pour vous comme vous

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

Vous devez également ajouter explicitement ce référentiel distant

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

• Retour rapide
• Simple à faire
• Simple à annuler