Sobre nosotros
En 1C no solo desarrollamos la plataforma en y , sino también aplicaciones en Java – en particular, un nuevo entorno de desarrollo basado en Eclipse y un servidor de mensajería profundamente integrado con la plataforma – .
Introducción
Como sistema de construcción para aplicaciones Java, solemos usar maven, y en este breve artículo nos gustaría hablar de uno de los problemas que hemos tenido que afrontar en el proceso de organización del desarrollo y de un enfoque que nos permitió superar este problema.
Supuestos y flujo de trabajo
Debido a la especificidad del desarrollo en nuestros proyectos de maven, usamos una cantidad considerable de módulos, dependencias y subproyectos. La cantidad de archivos pom en un árbol puede contarse por decenas e incluso cientos.
Podría parecer: no es para tanto, una vez que se crea, se olvida. Si necesitamos cambiar o agregar algo en todos los archivos a la vez, existen muchas herramientas convenientes en editores e IDE. ¿Y cuál es el cambio más común en pom.xml? Creemos que es la modificación de las versiones del proyecto y de las dependencias. Tal vez alguien quiera discutir esto, pero aquí la situación es así. La razón radica en que, junto con el núcleo, estamos desarrollando muchas bibliotecas propias, y para la constante reproducibilidad de los resultados de compilación y prueba, el uso de snapshots no nos parece un enfoque conveniente. Por esta razón, tenemos que aumentar el número de versión en los proyectos en cada compilación.
Además, el desarrollador de vez en cuando necesita compilar su propia rama de alguna biblioteca y comprobar su funcionamiento con todas las dependencias, para lo cual hay que cambiar manualmente la versión en todas ellas.
Solución inicial
Con tantos y múltiples cambios de versiones, el proceso dentro del CI quiere simplificarse y automatizarse. Aquí es donde entra en juego un conveniente y conocido complemento versions-maven-plugin – lo conectamos y lo ejecutamos
mvn -N versions:set -DnewVersion=2.0.1
y Maven hará todo como se debe: recorrerá la jerarquía de arriba a abajo, cambiará todas las versiones — ¡hermoso! Ahora solo queda enviar el pull-request, los compañeros revisarán los cambios y podré integrarme rápidamente en el trunk. ¿Rápidamente? Como si no fuera así. Un par de cientos pom.xml para revisión, y esto sin contar el código. Además, nadie está a salvo de conflictos de fusión con un número tan grande de archivos modificados. Aquí cabe señalar que en el proceso CI, los cambios de versión ocurren automáticamente junto con el cambio de funcionalidad, y no de forma separada.
Nuevas características
Por un tiempo nos calmamos y, resignados, así vivimos, hasta que los chicos de incluyeron en Maven, a partir de la versión 3.5.0-beta-1, el soporte para lo que se llaman 'sustitutos' de versiones (placeholders). La esencia de estos sustitutos es que en pom.xml lugar de indicar una versión específica del proyecto se utilizan variables ${revision}, ${sha1} y ${changelist}. Los propios valores de estas propiedades se establecen ya sea en el elemento <properties>, o se pueden definir a través de una propiedad del sistema
mvn -Drevision=2.0.0 clean package
Los valores de las propiedades del sistema tienen prioridad sobre los valores definidos en <properties>.
Padre
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>18<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<name>Primer CI Friendly<\/name>
<version>${revision}${sha1}${changelist}<\/version>
…
<properties>
<revision>1.3.1<\/revision>
<changelist>-SNAPSHOT<\/changelist>
<sha1\/>
<\/properties>
<\/project>
Hijo
<project>
<modelVersion>4.0.0<\/modelVersion>
<parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-parent<\/artifactId>
<version>${revision}${sha1}${changelist}<\/version>
<\/parent>
<groupId>org.apache.maven.ci<\/groupId>
<artifactId>ci-child<\/artifactId>
…
<\/project>
Si se quiere construir la versión 2.0.0-SNAPSHOT, simplemente se utiliza
mvn -Drevision=2.0.0 clean package
Si se quiere hacer un lanzamiento, simplemente reseteamos el SNAPSHOT
mvn -Dchangelist= clean package
*Los ejemplos anteriores se tomaron de en el sitio de Maven Apache Project
Realidad dura
Todo está bien y saludable, es hora de experimentar una sensación de satisfacción, pero no. Resulta que para install y deploy este método no funcionará, ya que en las descripciones de los artefactos que se publican en el repositorio no se cambiará ${revision} por su valor y Maven no entenderá de qué se trata.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Luz al final del túnel
Hay que buscar una solución al problema. La situación podría haber sido salvada por . Este plugin permite todas las variables en pom, pero también elimina mucha otra información que solo es necesaria durante la construcción y no se necesita al importar artefactos publicados en otros proyectos. Además, el plugin "aplana" todas las dependencias padre-hijo, resultando en poms planos que incluyen todo lo necesario. La desventaja era que elimina demasiado "innecesario", lo cual no nos agradaba. Tras investigar información sobre el desarrollo de este plugin, descubrimos que no éramos los únicos en el universo, y ya en agosto de 2018 se creó en GitHub, en el repositorio del plugin, un pull-request que solicitaba la opción de definir cómo se debe "modificar" pom.xml. Los desarrolladores escucharon las voces de los necesitados, y ya en diciembre, con el lanzamiento de la nueva versión 1.1.0, se añadió al flatten-maven-plugin un nuevo modo resolveCiFriendliesOnly, que llegó en el momento justo: deja pom.xml tal como está, excepto el elemento <version> y permite ${revision}, ${sha1} y ${changelist}.
Añadiendo el plugin al proyecto
<plugins>
<plugin>
org.codehaus.mojo
flatten-maven-plugin
1.1.0
<configuration>
true
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
flatten
process-resources
<goals>
flatten
</goals>
</execution>
<execution>
flatten.clean
clean
<goals>
clean
</goals>
</execution>
</executions>
</plugin>
</plugins>
¡Listo!
Final feliz
A partir de ahora, para cambiar la versión de todo el proyecto y notificar a todas las dependencias, solo tenemos que editar el elemento <revision> en un solo pom raíz pom.xml. En la revisión, no aparecen cientos de estos archivos con el mismo cambio, sino uno solo. Así también se elimina la necesidad de usar versions-maven-plugin.
Fuente: habr.com
