Fixing en caliente un error en una dependencia de la biblioteca de terceros

Question

Encontré un error menor en un marco de aplicación más grande que estoy usando. La fijación requiere solo cambiar dos líneas en una sola clase. Arreglé el problema y empujé los cambios al repositorio del proyecto.

Sin embargo, necesito lanzar mañana. Por lo tanto, no puedo esperar hasta que la biblioteca lance una nueva versión. Me pregunto cuál sería la mejor manera de integrar la versión parchada en mi proyecto:

• Construya el proyecto: esto me resulta bastante difícil, ni siquiera puedo construirlo correctamente, ya que muchas pruebas unitarias se rompen en el repositorio de instantáneas e incluso sin las pruebas unitarias no llego muy lejos porque obviamente me faltan algunas dependencias que no se pueden encontrar en Maven Central. Además, necesito enviar la versión fija a todos los demás desarrolladores, ya que no se puede encontrar en Maven Central. (Trabajamos en la red y no tenemos nuestro propio nexo).

• Agregar un nuevo módulo a mi proyecto donde mantengo una copia de la clase que he solucionado. Luego agrego este módulo como dependencia a todos los módulos que deberían usar la versión de anulación de la clase. Pero, ¿cómo está determinando la JVM qué clase realmente carga? Encontrará dos frasco-Cilos que contienen una clase con el mismo nombre. ¿Cuál cargará realmente? Si pudiera hacer que esto funcionara, esto me permitiría integrar la versión modificada de la clase con mi proyecto de modo que pueda distribuir el parche junto con el proyecto y una vez que el error se solucione, simplemente podría eliminar el módulo.

• Incluyo el archivo de clase modificado en el módulo afectado en sí. Hasta ahora, esta aparece como la solución más fácil para mí, ya que el JVM siempre cargará la clase desde el mismo frasco primero. (¿Estoy en lo cierto? Al menos eso es lo que observé en mis pruebas).

Gracias por cualquier opinión sobre esto.

Answer 1

Terminé construyendo el proyecto por separado y trasladando esta versión a otro espacio de nombres. Aparentemente, esto no es tan raro. Por ejemplo, Hibernate mantiene a CGLIB en su propio espacio de nombres para evitar conflictos de versión debido a los cambios de API.

• La primera solución sugerida tuvo un problema cuando el proyecto que utilicé también se usó en otra dependencia que condujo tanto a mi versión modificada como a la normal La versión estaba en la ruta de clase lo que condujo a un comportamiento muy extraño debido a los conflictos de nombres.

• La segunda y tercera sugerencia tuvieron problemas similares a la primera sugerencia. Además, rompí la compatibilidad con otras versiones de la dependencia.

Incluso suena doloroso: salir del espacio de nombres y proporcionar una construcción separada es imprescindible, incluso si solo cambia unas pocas líneas de código.

Answer 2

Creo que mover dependencias de su proyecto en espacios de nombres personalizados no es óptimo, por varias razones:

• Es probable que sus modificaciones no se envíen a los desarrolladores originales de la dependencia.
• Será difícil mantenerse al día con las nuevas versiones de dependencia, por lo que no más correcciones de errores, sin nuevas características, sin correcciones de vulnerabilidad de desarrolladores y contribuyentes de terceros.
• Mi experiencia es que con el tiempo se olvida cómo y por qué La dependencia personalizada se modificó. Esto dará como resultado que esta parte del proyecto no solo esté en desuso, sino también intocable, ya que nadie sabrá qué se romperá al reemplazarlo.

Estoy de acuerdo en que un flujo de trabajo que usa jitpack es la mejor solución. Escribí una publicación de blog con una guía detallada para hacerlo con solo un par de minutos de sobrecarga: https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

Answer 3

Tl; dr;

Visitar https://jitpack.io y lee como funciona

---

Pasos para resolver el problema

Supongo que la biblioteca de terceros está en GitHub, simplemente clona el proyecto y solucione.

Luego usa https://jitpack.io. Jitpack crea un .jar de su repositorio (donde arreglaste el código) y genera una dependencia para ti como

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

También debe agregar explícitamente este repositorio remoto

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

• Rápido
• Fácil de hacer
• Fácil de deshacer