Hace tiempo que no escribía, así que acá va una nueva entrada. Antes que nada, los que habrán leído alguna nota el año pasado o antes, habrán notado que la dirección del sitio cambió, la idea es apuntar un poco más a novedades y noticias en el mundo de los frameworks de las plataformas que manejo, con algún comentario de las cosas que me parecen interesantes, veremos si puedo llevarlo adelante.
Hoy quiero contarles acerca la experiencia que tuve, al querer implementar algo que, a priori, hubiera parecido bastante simple de hacer en el mundo de Maven, pero que, sorpresivamente no lo fue. De hecho fue la primera vez desde que utilizo esta herramienta, que tuve que tocar algo de código de un plugin desarrollado, ya que ninguna de las opciones que encontré pudo funcionar.
Lo que necesitaba (o mejor dicho, quería implementar) era poder enviar notificaciones automáticas vía correo electrónico, a los desarrolladores, cuando alguien hacía un release de uno de los componentes que utilizamos internamente en el lugar en donde trabajo.
Lo primero que hice, fue investigar dos plugins que realizaban parte de la tarea:
- Maven Changes Plugin: Este plugin construye una página o notificación, enumerando los "cambios" que tuvo un artefacto dado. Además ofrece la posibilidad de enviar el anuncio vía correo electrónico. Ya se lo que pensarán, este es el indicado, pero no. El problema es que elabora todo en base a dos orígenes: un archivo .xml que lista los cambios (changes.xml), o sino utiliza un repositorio de issues como Jira o Trac. Justamente en mi trabajo no usamos ninguno de esos repositorios de issues por lo que ninguno de los orígenes de "cambios" me servía. Yo necesitaba que tome los mismos del SVN (repositorio de código).
- Maven Changelog Plugin: Este otro tenía justamente lo que el anterior no tenía, es decir, lo que hace es elaborar un reporte que lista los cambios que existen en el repositorio de código. El problema es que es lo único que hace (o sea, no arma anuncios ni envía correos). Además el reporte es bastante pobre, ya que no "decora" de ninguna manera los commits, no enlaza los issues a nuestra herramienta de gestión de issues, ni nada por el estilo.
Bastante decepcionado seguí buscando a ver si encontraba algo que podría servirme sin éxito. Hasta que ingresé al repositorio de plugins de Codehaus. Buscando en este lugar, encontré un plugin bastante interesante, el SCM Changelog Maven plugin. Inicialmente parecía ser la solución, ya que creaba un reporte bastante parecido al que genera el Maven Changes Plugin, pero lamentablemente no enviaba anuncios. Igualmente lo investigué para por lo menos poder crear el reporte, pero me encontré con otros problemas:
- Cuando quise ejecutarlo, me encontré con que arrojaba una excepción, buscando en la lista de issues abiertos, lamentablemente encontré que el problema no estaba solucionado aún.
- No encontré ninguna configuración que permita filtrar los textos de los commits, esto era importante debido a que como utilizamos releases automáticos vía maven, muchos textos sería interesante que no aparezcan, ya que se trata de commits automáticos.
- Si bien soporta el concepto de Grammars, para identificar los issues que uno menciona en los textos de los commits, necesitaba la posibilidad de definir una grammar personalizada, ya que utilizamos una forma especial de nombrar los issues. Esto sumado al hecho de que los issues los tenemos almacenados en una herramienta propietaria (ni Jira ni Trac+)
Debido a todos estos problemas, decidí ponerme manos a la obra, descargarme el código fuente del plugin y ver si podía solucionarlos.
Luego de investigar y probar, logré solucionar el primer problema, el cual ocurría debido a que en Maven 3, se cambió todo el mecanismo de generación de reportes y manejo de repositorios, haciendo que no se pueda subclasear el repository manager para agregarle nuevas características.
Lo que hice fue modificar la clase ScmActivityReport, e instanciar el repository manager usando el BasicScmManager, ya que no era necesario reemplazar el que provee Maven, ya que el único uso es generar el reporte, y con ese era suficiente.
![]() |
Instanciación del BasicScmManager |
En esa clase también aproveché para hacer algunas modificaciones visuales al reporte, como por ejemplo ponerle un border a la tabla, comentar la sección de resumen, hacer que las referencias a los íconos sean a imágenes públicas y poner un título personalizado.
El segundo paso fue crear un nuevo Grammar, el cual como primer medida, filtra de todos los mensajes de los commits, todos los que tengan el texto "maven-release-plugin", esto es porque no quiero que aparezcan como cambios los commits que haga el plugin de maven, ya que no aportan nada al changelog.
Además aproveché el hecho de tener un nuevo grammar propio, y modifiqué los patrones de búsqueda de issues en el texto del comentario del commit, para que encuentre los issues que yo quería que encuentre.
Para crearse su propio grammar, pueden ver la documentación del plugin, que es bastante simple.
Otra cosa que tuve que hacer, fue tocar la clase SvnScmAdapter y comentar ciertas líneas (104-115) que agregaban como un "release" a los cambios hechos en el trunk. Eso era algo que no necesitaba, ya que lo que yo quería, era apuntar a los tags que crea el Maven Release Plugin.
Finalmente tuve que implementar unos cambios en la clase SvnListConsumer, ya que el filtrado de tags aceptados se hacía antes de agregar un tag ficticio que contiene los cambios hasta antes de la creación del primer tag, lo cual es un problema, ya que lo que yo necesitaba era que se muestren solamente los cambios del tag sobre el cual se hizo el release.
![]() |
Modificaciones al SvnListConsumer |
De todas maneras solo tenía la primer parte del trabajo realizada hasta este punto. Hasta ahora solo tenía un reporte en html, con el formato de maven, con todos los cambios de la versión que fue liberada en el build actual. Yo lo que quería era que ese reporte se envíe mediante correo electrónico.
Para esto último, estuve investigando, y de todas las opciones disponibles, la que más me gustó fue el Maven Postman Plugin, el cual, lo que hace es enviar un correo electrónico, cuyo contenido es un html presente en el directorio de construcción de nuestro proyecto.
La configuración es simple, y pueden visitar este post, en donde se explican algunos detalles importantes.
El problema, ahora, era que el reporte era generado con el look & feel de los sites de maven, con un menu al costado, etc. Yo quería que el mail enviado sea lo más "limpio" posible.
La solución fue proporcionar un nuevo template, el cual era basado en el template original, y lo que hice, fue eliminar las secciones del header, footer, y menu. Lo que sí, tuve que usar el Maven Dependency Plugin, para empaquetar el template en un artefacto aparte, y que se pueda desempaquetar en todos los proyectos de forma dinámica, y evitar tener que incluirlo dentro de cada proyecto desde el cual yo quiera enviar notificaciones.
Finalmente lo que hice fue modificar el profile "release-profile", el cual es un profile built-in el cual se activa automáticamente al momento de hacer un release. Lo que hice fue agregar las configuraciones de todos los plugins mencionados hasta ahora. Obviamente tuve que compilar mi propia version del ScmChangelogPlugin y deployarla en nuestros servidores privados de binarios. Les paso la configuración final:
<profile>
<id>release-profile</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>site</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>assemblies-comunes</groupId>
<artifactId>assemblies-comunes</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/unpackedAssemblies</outputDirectory>
<destFileName>optional-new-name.jar</destFileName>
<includes>**/*.vm</includes>
</artifactItem>
</artifactItems>
<includes>**/*.vm</includes>
<outputDirectory>${project.build.directory}/assemblies</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>ch.fortysix</groupId>
<artifactId>maven-postman-plugin</artifactId>
<executions>
<execution>
<id>send a mail</id>
<phase>site</phase>
<goals>
<goal>send-mail</goal>
</goals>
<inherited>true</inherited>
<configuration>
<from>ciserver@miempresa.com</from>
<subject>Release exitoso: ${project.artifactId}-${project.version}</subject>
<failonerror>false</failonerror>
<mailhost>mail-pruebas.miempresa.com</mailhost>
<mailuser>user</mailuser>
<mailpassword>password</mailpassword>
<htmlMessageFile>target/site/changelog.html</htmlMessageFile>
<receivers>
<receiver>Programadores</receiver>
<receiver>programadores@miempresa.com</receiver>
</receivers>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<configuration>
<templateDirectory>${basedir}/target/unpackedAssemblies</templateDirectory>
<template>template-changelog.vm</template>
</configuration>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>scmchangelog-maven-plugin</artifactId>
<version>1.4-SNAPSHOT</version>
<configuration>
<trackerUrlPattern>http://miherramientadeissues.miempresa.com?idIssue={0}</trackerUrlPattern>
<trackerType>sourceforge</trackerType>
<grammar>MIGrammar</grammar>
<filter>${project.artifactId}-${project.version}</filter>
</configuration>
</plugin>
</plugins>
</reporting>
</profile>
Fue complejo, pero al final logré lo que quería. Veré si tengo algo de tiempo, en contactarme con los creadores del plugin a ver si se pueden incorporar algunas de las correcciones y mejoras que implementé.
Nos vemos en el proximo post!
0 comentarios:
Publicar un comentario