Skip to main content

“El arte de la guerra” y los conflictos de dependencias

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (8 votos, promedio: 4,63 de 5)
Cargando…

Desde hace unos años me dedico a los eventos, me refiero a esos eventos que se utilizan para transportar información, no a los del tipo BBC (bodas, bautizos y comuniones); pero en un día cualquiera de trabajo en el que estaba rumiando un tema sobre el que escribir, dos sucesos no relacionados entre sí y que se produjeron con una diferencia de minutos, guardaban una curiosa relación “conflictos de librerías”.

Evento 1/2: Por un lado había terminado de actualizar un microservicio a la última versión de Spring Data MongoDB para así poder atacar colecciones shardeadas y de paso utilizar una versión del driver de MongoDB más reciente. El caso, que no viene a cuento, es que me ofrecí voluntario para tal tarea y al explicar lo que había tenido que hacer me dio la impresión que mis escuchantes no parecían saber de qué estaba hablando, lo que viene siendo un obelobolebolobe.

La principal virtud de Spring es el desacoplamiento y su principal defecto es el desacoplamiento porque Spring resuelve en tiempo de ejecución qué clases se han de utilizar. El típico “en mi equipo funciona” se debe a que donde tiene que funcionar es en un contenedor (entiéndase contenedor en el más amplio sentido de la palabra) que establece una serie de librerías que tenemos que considerar en desarrollo, y que si empezamos a añadir dependencias a nuestros proyectos, es muy probable que estemos generando conflictos. A veces las cosas funcionan sin darnos cuenta y parece que todo está bien; otras no funcionan lo que significa que hay algo que arreglar; y luego están las peores que son las que funcionan casi siempre y como tal no tenemos ni idea de lo que se tiene que arreglar, esto último es lo que yo llamo poltergeists.

 

Los golpes son los cabezazos que se suelen pegar en la mesa y los sonidos son los exabruptos que uno suelta; los fenómenos inexplicables es lo que voy a intentar explicar cómo evitarlos.

Evento 2/2: Estaba viendo en background (suena cool pero no es más que darle al play y no hacerle caso) este interesante video sobre la experiencia de Spotify con Apache Beam y me llamó la atención lo siguiente:

Problemas con versiones las he vivido en diversas ocasiones a lo largo de décadas: desde aplicaciones JEE usando Xerces (como diría el abuelo de Érase una vez los informáticos: “Querido nietecito, el Weblogic 6 introdujo la configuración por XML…”) hasta procesos Spark en Cloudera (“Welcomeeeeeeeeeee to Jumanji”); nuestros proyectos utilizan unas versiones y los contenedores otras así que veamos que tenemos que hacer para evitarnos berrinches.

Lo primero, indicar que no es una cuestión que se arregle a nivel de código sino que se soluciona a nivel de proyecto. Lo segundo es que no sabemos si nos llevará horas, días o semana (a partir de la semana los daños cerebrales son irreparables y aconsejo salir pitando).

Así que veamos cómo las enseñanzas de nuestro respetado general nos ayudan a resolver estas situaciones.

Sun Tzu dice “Haz tuyas las dependencias de tu enemigo”

Si sabes que el contenedor te va a imponer una serie de dependencias lo que tienes que hacer es añadirlas de inicio a tu proyecto. Así hice con Cloudera y desde entonces mi vida mejoró notablemente. Me cogí la lista de librerías que Cloudera impone en Spark y las añadí a un proyecto que aplicaba en todos mis desarrollos Spark.

Sun Tzu dice “No te confíes y evita los conflictos”

Antes de hacer commit, aunque todos tus tests funcionen, elimina los conflictos. En la mayoría de ocasiones basta con hacer un exclude.

Sun Tzu dice “Si el conflicto es inevitable busca siempre la sombra”

A veces el conflicto se produce sí o sí. Yo me lo he encontrado con los ya mencionados procesos Spark que tenían que guardar datos en ElasticSearch. Cloudera estaba aplicando dependencias, no recuerdo si a nivel de Lucene o de ElasticSearch, que entraban en conflicto con la versión de la base de datos ElasticSearch. En estos casos no queda otra que “shadear” que no es más que mover determinadas dependencias de paquete. Igualmente se resuelve vía plugin.

Y como conclusión de esta humilde entrada un sencillo consejo: La madre de todas las ciencias, la paciencia. Esto con tiempo y sosiego se arregla fácil. Has pronto “nietecitos”.

Alberto Rodríguez Berzal

Alberto Rodríguez Berzal

Arquitecto software, especialista SOA&BPM, programador multilenguaje, experto J2E, administrador Weblogic y más. Con más de 15 años de experiencia profesional y 25 como programador, pero solo uno haciendo cerveza casera.

Alberto Rodríguez Berzal ha escrito 3 entradas


Alberto Rodríguez Berzal

Alberto Rodríguez Berzal

Arquitecto software, especialista SOA&BPM, programador multilenguaje, experto J2E, administrador Weblogic y más. Con más de 15 años de experiencia profesional y 25 como programador, pero solo uno haciendo cerveza casera.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.