Diario de Programación

Hace tiempo que tengo una necesidad en el trabajo y que he ido dejando olvidada por falta de tiempo. Cuando en maven manejas proyectos grandes, cada uno con varios subproyectos  y encima esos proyectos grandes dependen de otros proyectos grandes que también tienen sus subproyectos, llevar un versionado en condiciones de cada jar puede ser un infierno.

Me explico, tu proyecto grande lleva un fichero pom.xml. Cada uno de los subproyectos también. En los demás proyectos también y en sus subproyectos también. Algunos de los jar de alguno de esos subproyectos pueden ser librerías básicas, por ejemplo, una librería de componentes swing o de utilidades para acceso a base de datos, de gráficos, o lo que sea. Aparecen dependencias de esa librería en los pom.xml de muchos de los proyectos y subproyectos.

¿Qué pasa si cambiamos la versión de esa librería?. Que no queda más remedio que ir en todos los proyectos y subproyectos en los que queremos actualizar la versión buscando dicha librería por los pom.xml y cambiando el número de versión. Desde luego, una tarea rutinaria, pero algo aburrida, que lleva un tiempo y susceptible de error "humano" al hacerla a mano.

Así que pensé en hacer un script o algo que buscara por los pom.xml y cambiara automáticamente las versiones que se le dijeran. Así que por fin me puse a ello y como siempre, para jugar y aprender algo nuevo, en vez de un script, decidí hacerlo como plugin de maven.

El resultado es un plugin de maven con dos goals:

• lista saca en un fichero un listado de todos los artifacts que aparecen en el pom.xml del proyecto y subproyectos actuales y con la nueva versión o groupId que queremos para cada sub/proyecto. Ese fichero lo utilizará el siguiente goal para hacer los cambios en el pom.xml.
• cambia realiza los cambios indicado en el fichero anterior en todos los pom.xml que encuentre del proyecto y subproyecto. 
  • Si se ejecuta este goal en el mismo proyecto en que se ejecutó el lista, obtenemos un cambio de versión en el proyecto. Quizás el plugin release de maven hace esto mismo y mejor.
  • Si se copia el fichero de cambios en otros proyecto distinto y ejecutamos allí el goal cambia, conseguimos cambiar la versión de las dependencias con el primer proyecto.

Lo he estado usando ya y probando, va bastante bien, aunque veo que el uso no es demasiado intuitivo, siempre se me olvida hacer alguna cosa.

Ahí van un par de enlaces:

• Proyecto en chuidiang : http://proyectos.chuidiang.com/pom_version/index.html
• Proyecto en google-code: http://code.google.com/p/chuidiang-pom-version/

Aprender, pues aprendí algunas cosillas, sobre todo, ¿cómo no?, problemas con los que me he tropezado. El más gordo ha sido que no hay forma de hacer un deploy de un plugin en condiciones. En el pom.xml del plugin, el packaging es "maven-plugin". Pues el deploy no sabe hacer un deploy de una cosa cuyo packaging es "maven-plugin", así que para que funcione el deploy, debes poner packaging "jar". Pero claro, eso sube el fichero .pom al repositorio remoto con ese packaging que no es, así que luego, a mano y en el repositorio remoto, tienes que cambiar el "jar" por "maven-plugin" otra vez. Y el problema sigue, ya que al cambiar eso a mano, los ficheros de checksum/huella o como quieras llamarle .md5 y .sha1 que se crean en el repositorio remoto ya no cuadran y al bajarte el plugin con maven dan un warning.

Y yo creo que ya está bien de proyectos. Esta tarde me dedicaré a otra cosa.

Hace tiempo me puse a hacer en perl, por aquello de aprender perl, un script que me pasara tipos de ficheros .h de C a clases java, de forma que pudiera enviarlas y recibirlas por socket desde un ejecutable C a uno Java y viceversa. Con ese experimento, aprendí el tema de expresiones regulares algo más en serio. Luego, para sorpresa mía, vi que en java las expresiones regulares son calcaditas a las de perl, y que se parecen mucho a las del editor vi y que finalmente supongo que vienen del mundo unix. Así que me quedé con las ganas de hacer algo un poco más en serio con expresiones regulares en java.

Otra cosa que tenía pendiente es la de conectarme desde java a una URL y ver cómo bajar el fichero correspondiente a esa URL, bien sea un html, bien sea un doc, un pdf o una foto.

Así que junté lo uno con lo otro y para probar más que por otro motivo, decidí hacer un descargardor de ficheros de páginas web. La idea es darle una página html, que se la descargue, que busque dentro todos los href y que si apuntan a ficheros con determinadas extensiones, que se las descargue también. Eso cumple ambos requisitos, jugar con las expresiones regulares y descargar ficheros de una URL.

Me puse con ello y he estado en ello hasta que me ha aburrido el tema (ya no iba a aprender nada más sin meterme en camisa de once varas) y he probado un poco para ver que más o menos funciona, pero a pesar de todo ello, me he decidido a ponerlo en la web.

Así que en el repositorio maven de chuidiang.com están los jar y los fuentes empaquetados en un jar del descargador.

En la parte de proyectos, he puesto la documentación generada por maven de dicho descargador.

Y finalmente, para rizar el rizo, he creado en google code el proyecto chuidiang-descargador, para que los fuentes estén accesibles vía subversion. La verdad es que mi primera intención era meterlos en el repositorio launchpad de bazaar, pero no me funcionó a la primera por problemas de seguridad, firmas digitales, claves públicas y privadas y como no sé del tema más que lo básico, pero nada de lo práctico y como encima windows no ayuda a estas cosas, pues lo dejé en subversion de google-code.

Hace unos días comentaba si la habría cagado al aceptar un puesto un poco más de "jefecillo" que antes. Y efectivamente, compruebo que la he cagado. La prueba de ello es que en vez de hacer código, me estoy dedicando a mirar cosas como statcvs, una herramienta que mira el log de todos los commits que se han hecho en un proyecto en CVS y luego saca un montón de gráficos molones, inútiles, pero molones.

Aquí van unos cuantos ejemplos. El siguiente es un gráfico que muestra los commits como puntitos de varios desarrolladores a lo largo de cerca de cuatro años. Me he cargado el nombre del proyecto y de los desarrolladores, por  aquello de la discrección. En cada gráfico, el eje y son las horas del día, de 0 a 24. En el eje x son los días a lo largo de los años. El primer gráfico, de puntitos azules, muestra el total de commits del proyecto. Los siguientes, con puntitos rojos, cada uno de los desarrolladores.

Llama la atención el tercer desarrollador, que se fue a teletrabajar hace un año. Se nota claramente que desde ese día NO tiene horarios. Antes hacía commits de 8 a 6, horario de oficina. Ahora es habitual que haga commits a la una de la madrugada.

También llama la atención el último, con una densidad de commits especialmente alta. Se ve que es amigo de CVS. Curiosamente, se ve una pequeña franja horizontal sin commits, correspondiente a la hora de comer.

En el sexto desarrollador, hacia el principio del gráfico, también se ven unos días de agobio. con un commit pasada la media noche.

También se ve, gracias a Dios, que en mi empresa tenemos un horario en general normal. Son raros los commits más allá de las seis de la tarde.

y en este otro gráfico, se ve cómo han ido añdiendo líneas de ćodigo en otro proyecto distintos desarrolladores. Las grandes subidas se deben posiblemente a copy-paste de otros proyectos (vergüenza) o bien a "refactoring" intensivo, a base de mover grandes fuentes bloques de fuente de un sitio a otro (espero que sea eso). En la parte baja estaba el nombre de los desarrolladores, asociado a cada una de las líneas de color, pero me los he cargado.

y aunque no he puesto ejemplos, también hay gráficos para cada desarrollador indicando en qué horas del día mete más en CVS o en que días de la semana. Aunque en general este tipo de gráficos si es más o menos aleatorio, a veces se ve gente que tiende a meter en CVS los viernes, o bien justo antes de comer o de irse a casa por la tarde. Supongo que eso también es una mala costumbre, da la impresión de que no meten el código cuando lo han probado bien, sino como una especie de "backup" de su trabajo diario, metiendo en CVS cosas que quizás no están lo suficientemente probadas.

Aquí puedes ver un ejemplo completo de los gráficos estadíscos generados por statcvs.

Acabo de subir a google-code los fuentes de otro pequeño proyecto que me traigo entre manos, chuidiang-editores.

De momento son simplemente unas clases que heredan de JFormattedTextField y hace de editores simples: un EditorNumerico, EditorDate, EditorLongitud, EditorLatitud, etc. Por supuesto, intentando que sólo admitan números correctos, que se puedan poner restricciones, como que el número esté entre un mínimo y un máximo, etc.

También hay un EditorPanelGeneral. Es un JPanel al que se añaden editores de una forma simple y él se encarga del Layout y de colocarlos de forma automática. Este JPanel admite como dato un Hashtable. Con las claves identifica a qué editor pertenece el dato y se lo pasa. En el método getDato() devuelve un Hashtable con los datos de cada uno de los editores.

Y eso es más o menos lo que hay. La intención final es ligar todo esto con base de datos, de forma que para un conjunto de columnas dadas de unas tablas, se construya automáticamente el formulario y más adelante, facilitar también el tema de consultas e inserciones, así como la presentación en un JTable de los resultados, con sus botones de crear/editar/borrar, filtro, etc.

Ahí van algunos enlaces:

• La documentación del proyecto: http://proyectos.chuidiang.com/editores/
• El proyecto en google-code: http://code.google.com/p/chuidiang-editores/
• Repositorio Maven: http://maven2.chuidiang.com/com/chuidiang/ChuidiangEditores/

y sólo falta lo de siempre, porque empezar he empezado con ganas. Lo que hay que ver es lo que dura.