Experiencia usando flatten-maven-plugin para simplificar el control de versiones en proyectos maven

Acerca de nosotros

En 1C, desarrollamos no solo la plataforma 1C: Enterprise en C ++ y JavaScript , sino también aplicaciones Java, en particular, el nuevo entorno de desarrollo de Enterprise Development Tools basado en Eclipse y un servidor profundamente integrado con la plataforma de mensajería: Interaction Systems .

Entrada

En la mayoría de los casos, utilizamos maven como sistema para ensamblar aplicaciones Java, y en este breve artículo nos gustaría hablar sobre uno de los problemas que tuvimos que enfrentar durante el proceso de desarrollo y el enfoque que nos permitió superar este problema.

Fondo y flujo de trabajo

Debido a los aspectos específicos del desarrollo en nuestros proyectos maven, utilizamos muchos módulos, dependencias y proyectos secundarios. El número de archivos pom en un árbol puede ser decenas o incluso cientos.



Parecería: está bien, una vez creado y olvidado. Si necesita cambiar o agregar algo en todos los archivos a la vez, hay muchas herramientas convenientes en editores e IDEs. ¿Y cuál es el cambio regular más común a pom.xml? Creemos que cambiar las versiones del proyecto y las dependencias. Tal vez alguien quiera discutir con esto, pero este es el caso con nosotros. La razón es que, junto con el núcleo, estamos desarrollando simultáneamente muchas de nuestras propias bibliotecas, y para la reproducibilidad constante del ensamblaje y los resultados de las pruebas, el uso de instantáneas no nos parece un enfoque conveniente. Por este motivo, es necesario aumentar el número de versión en los proyectos en cada ensamblaje.

Además, el desarrollador de vez en cuando existe la necesidad de recopilar su propia rama de una biblioteca y verificar su rendimiento en relación con todas las dependencias, por lo que todos ellos tienen que cambiar manualmente la versión.

Decisión inicial

Con cambios de versión tan frecuentes y múltiples, el proceso dentro de CI quiere ser simplificado y automatizado. Aquí el conveniente complemento conocido -maven-plugin viene al rescate - lo enchufamos y ejecutamos

mvn -N versiones: set -DnewVersion = 2.0.1

y el Maven hará todo como debería: recorrer la jerarquía de arriba a abajo, reemplazar todas las versiones, ¡belleza! Ahora queda por elevar la solicitud de extracción, los colegas observarán los cambios y podrá unirse rápidamente al tronco. Rápidamente? No importa como. Un par de cientos de pom.xml por revisión, y eso sin contar el código. Además, nadie está a salvo de conflictos de fusión con una cantidad tan grande de archivos modificados. Cabe señalar aquí que durante el proceso de CI, los cambios de versión ocurren automáticamente junto con un cambio en la funcionalidad, y no de alguna manera por separado.

Nuevas características

Durante un tiempo, nos calmamos y vivimos en paz, hasta que los chicos del Proyecto Maven Apache incluidos en maven, comenzando con la versión 3.5.0-beta-1, soporte para los llamados "marcadores de posición" de versiones (marcadores de posición). La esencia de estos sustitutos es que las variables $ {revision} , $ {sha1} y $ {changelist} se usan en pom.xml en lugar de especificar la versión del proyecto. Los valores de estas propiedades se establecen en el elemento < propiedades > o se pueden definir a través de la propiedad del sistema

mvn -Drevision = 2.0.0 paquete limpio

Los valores de las propiedades del sistema tienen prioridad sobre los valores definidos en < propiedades >.

El padre
<proyecto>
<modelVersion> 4.0.0 </modelVersion>
<parente>
<groupId> org.apache </groupId>
<artifactId> apache </artifactId>
<version> 18 </version>
</parent>
<groupId> org.apache.maven.ci </groupId>
<artifactId> ci-parent </artifactId>
<name> Primer CI amigable </name>
<version> $ {revision} $ {sha1} $ {changelist} </version>
...
<propiedades>
<revision> 1.3.1 </revision>
<changelist> -SNAPSHOT </changelist>
<sha1 />
</properties>
</project>

Descendiente
<proyecto>
<modelVersion> 4.0.0 </modelVersion>
<parente>
<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 desea compilar la versión 2.0.0-SNAPSHOT, simplemente use

mvn -Drevision = 2.0.0 paquete limpio

Si quieres hacer un lanzamiento, entonces solo cero a cero INSTANTÁNEA

mvn -Dchangelist = paquete limpio

* Los ejemplos anteriores están tomados de un artículo en el sitio web del Proyecto Maven Apache

Dura realidad

Todo es bueno y saludable, es hora de experimentar una sensación de satisfacción, pero no. Resulta que para instalar e implementar este método no funcionará, porque $ {revisión} no será reemplazado por su valor en las descripciones de los artefactos publicados en el repositorio y Maven no entenderá de qué se trata.

<parente>
<groupId> org.apache </groupId>
<artifactId> apache </artifactId>
<version> $ {revision} </version>
</parent>

Luz al final del túnel.

Debemos buscar una solución al problema. La situación podría haber sido salvada por un complemento flatten-maven . Este complemento permite todas las variables en pom, pero al mismo tiempo elimina una tonelada de otra información que solo se necesita durante el ensamblaje y no se necesita al importar artefactos publicados a otros proyectos. Además, el complemento "endereza" todas las dependencias padre-hijo, y como resultado obtenemos pom plano, que incluye todo lo que necesita. El inconveniente era que cortaba "demasiado" demasiado, lo que no nos convenía en absoluto. Después de estudiar la información sobre el desarrollo de este complemento, resultó que no somos los únicos en el universo, y en agosto de 2018 se creó una solicitud de extracción en el github en el repositorio del complemento con el deseo de permitir determinar independientemente cómo "estropear" pom.xml. Los desarrolladores escucharon las voces de los afectados, y ya en diciembre, con el lanzamiento de la nueva versión 1.1.0, apareció un nuevo modo resolveCiFriendliesOnly en flatten-maven-plugin, que como nunca antes, deja pom.xml tal como está, excepto por el elemento <version> y permite $ {revision} , $ {sha1} y $ {changelist} .

Agregar un complemento al proyecto

<plugins>
<plugin>
<groupId> org.codehaus.mojo </groupId>
<artifactId> flatten-maven-plugin </artifactId>
<version> 1.1.0 </version>
<configuración>
<updatePomFile> true </updatePomFile>
<flattenMode> resolveCiFriendliesOnly </flattenMode>
</configuration>
<ejecuciones>
<ejecución>
<id> aplanar </id>
<phase> recursos de proceso </phase>
<objetivos>
<goal> aplanar </goal>
</goals>
</execution>
<ejecución>
<id> flatten.clean </id>
<phase> clean </phase>
<objetivos>
<goal> limpio </goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>


Hecho

Final feliz

De ahora en adelante, para cambiar la versión de todo el proyecto y dejar que todas las dependencias lo sepan, solo necesitamos editar el elemento < revision > en un solo pom.xml raíz. No son cien o dos de estos archivos con el mismo cambio que se incluyen en la revisión, sino uno. Bueno, no hay necesidad de usar versiones-maven-plugin .