Fillare a caldo un bug in una dipendenza della libreria di terze parti

Question

Ho trovato un bug minore in un framework di applicazioni più grande che sto usando. Il fissaggio richiede solo di cambiare due righe in una singola classe. Ho risolto il problema e ho spinto le modifiche al repository del progetto.

Tuttavia, devo rilasciare domani. Pertanto, non posso aspettare che la libreria rilasci una nuova versione. Mi chiedo quale sarebbe il modo migliore per integrare la versione patchati nel mio progetto:

• Costruisci il progetto: questo trovo abbastanza difficile, non posso nemmeno costruirlo correttamente poiché così tanti test unitari sono interrotti nel repository di istantanee e anche senza i test unitari non vado molto lontano poiché ovviamente mi mancano alcune dipendenze che non possono essere trovate a Maven Central. Inoltre, devo inviare la versione fissa a tutti gli altri sviluppatori poiché non può essere trovata su Maven Central. (Lavoriamo in rete e non abbiamo il nostro Nexus.)

• Aggiunta di un nuovo modulo al mio progetto in cui tengo una copia della classe che ho risolto. Quindi aggiungo questo modulo come dipendenza a tutti i moduli che dovrebbero utilizzare la versione sovrascritta della classe. Ma come sta determinando JVM quale classe si carica effettivamente? Ne troverà due barattolo-File che contengono una classe con lo stesso nome. Quale verrà effettivamente caricato? Se potessi fare questo lavoro, questo mi consentirebbe di integrare la versione modificata della classe con il mio progetto in modo tale da poter distribuire la patch insieme al progetto e una volta che il bug viene risolto, potrei semplicemente rimuovere il modulo.

• Sto includendo il file di classe modificato nel modulo stesso interessato. Finora, questa appare come la soluzione più semplice per me poiché la JVM caricherà sempre prima la classe dallo stesso barattolo. (Ho ragione? Almeno questo è quello che ho osservato nei miei test.)

Grazie per qualsiasi input su questo.

Answer 1

Ho finito per costruire il progetto separatamente e spostare questa versione in un altro spazio dei nomi. Apparentemente questo non è così raro. Ad esempio Hibernate mantiene CGLIB nel proprio spazio dei nomi per evitare conflitti di versione a causa delle modifiche dell'API.

• La prima soluzione suggerita ha avuto un problema quando il progetto che ho usato è stato utilizzato anche in un'altra dipendenza ciò che ha portato a quella versione modificata sia normale La versione era sul percorso di classe ciò che ha portato a un comportamento molto strano a causa dei conflitti di denominazione.

• Il secondo e il terzo suggerimento hanno avuto problemi simili al primo suggerimento. Inoltre, ho rotto la compatibilità con altre versioni della dipendenza.

Anche sembra doloroso: uscire dallo spazio dei nomi e fornire una build separata è un must, anche se si cambia solo alcune righe di codice.

Answer 2

Penso che spostare le dipendenze del tuo progetto in spazi dei nomi personalizzati non sia ottimale, per diversi motivi:

• Le tue modifiche probabilmente non verranno rispediti agli sviluppatori originali della dipendenza.
• Sarà difficile tenere il passo con le nuove versioni di dipendenza, quindi non più fisi di bug, nessuna nuova funzionalità, nessuna correzione di vulnerabilità da sviluppatori e collaboratori di terze parti.
• La mia esperienza è che nel tempo viene dimenticata come e perché La dipendenza personalizzata spaziata è stata modificata. Ciò comporterà che questa parte del progetto sia non solo deprecata, ma anche intoccabile, poiché nessuno saprà cosa si romperà quando lo sostituirà.

Sono d'accordo che un flusso di lavoro che utilizza Jitpack è la soluzione migliore. Ho scritto un post sul blog con una guida dettagliata per farlo con solo un paio di minuti di sovraccarico: https://5am.technology/2016/12/fix-bugs-third-party-dipendency-jitpack/

Answer 3

Tl; dr;

Visitare https://jitpack.io e leggi come funziona

---

Passi per risolvere il problema

Supponendo che la libreria di terze parti sia su Github, semplicemente clona il progetto e risolverlo.

Quindi usa https://jitpack.io. Jitpack crea un .jar dal tuo repository (dove hai risolto il codice) e genera una dipendenza per te come

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

Inoltre è necessario aggiungere esplicitamente questo repository remoto

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

• Lavoro veloce
• Semplice da fare
• Semplice da annullare