Sobre nosotros
En 1C desarrollamos no solo una plataforma en и , pero también aplicaciones Java, en particular el nuevo entorno de desarrollo. basado en Eclipse y un servidor de mensajería profundamente integrado con la plataforma - .
Entrada
La mayoría de las veces usamos maven como sistema de compilación para aplicaciones Java, y en este breve artículo nos gustaría hablar sobre uno de los problemas que tuvimos que enfrentar en el proceso de organización del desarrollo y sobre el enfoque que nos permitió superarlo. problema.
Requisitos previos y flujo de trabajo
Debido a las características específicas del desarrollo de nuestros proyectos maven, utilizamos bastantes módulos, dependencias y proyectos secundarios. La cantidad de archivos pom en un árbol puede ser de decenas o incluso cientos.
Parecería: no es gran cosa, lo crearon una vez y se olvidaron de él. Si necesita cambiar o agregar algo en todos los archivos a la vez, existen muchas herramientas convenientes en editores e IDE. ¿Cuál es el cambio regular más común en pom.xml? Creemos que los cambios en las versiones y dependencias del proyecto. Quizás alguien quiera discutir esto, pero esta es exactamente nuestra situación. La razón radica en el hecho de que, junto con el kernel, estamos desarrollando simultáneamente muchas de nuestras propias bibliotecas y, para la constante reproducibilidad de los resultados de la compilación y 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 con cada compilación.
Además, de vez en cuando, un desarrollador necesita crear su propia rama de una biblioteca y comprobar su funcionalidad con todas las dependencias, para lo cual tiene que cambiar manualmente la versión de todas ellas.
Solución inicial
Con cambios de versión tan frecuentes y múltiples, quiero simplificar y automatizar el proceso dentro de CI. Aquí es donde viene al rescate un complemento conveniente y conocido. versiones-maven-plugin - conéctalo y ejecútalo
mvn -N versiones:set -DnewVersion=2.0.1
y Maven hará todo como debería: recorrerá la jerarquía de arriba a abajo, reemplazando todas las versiones: ¡belleza! Ahora todo lo que queda es generar una solicitud de extracción, los colegas revisarán los cambios y usted podrá unirse rápidamente al tronco. ¿Rápidamente? No importa cómo sea. 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 una cantidad tan grande de archivos modificados. Cabe señalar aquí que en el proceso de CI, los cambios de versión se producen automáticamente junto con los cambios en la funcionalidad, y no de alguna manera por separado.
Nuevas funciones
Por un tiempo nos calmamos y, resignados, vivimos así hasta que los chicos de A partir de la versión 3.5.0-beta-1, Maven no incluyó soporte para los llamados "marcadores de posición". La esencia de estos sustitutos es que pom.xml en lugar de una indicación específica de la versión del proyecto, se utilizan variables ${revisión}, ${sha1} и ${lista de cambios}. Los valores de estas propiedades se establecen en el elementopropiedades>, o se pueden definir a través de una propiedad del sistema
mvn -Drevision=2.0.0 paquete limpio
Los valores de las propiedades del sistema tienen prioridad sobre los valores definidos enpropiedades>.
El padre
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-padre
Primer CI amigable
${revisión}${sha1}${lista de cambios}
...
1.3.1
-INSTANTÁNEA
Descendiente
4.0.0
org.apache.maven.ci
ci-padre
${revisión}${sha1}${lista de cambios}
org.apache.maven.ci
ci-niño
...
Si desea compilar la versión 2.0.0-SNAPSHOT, simplemente use
mvn -Drevision=2.0.0 paquete limpio
Si desea realizar un lanzamiento, simplemente reinicie SNAPSHOT
mvn -Dchangelist= paquete limpio
*Los ejemplos anteriores están tomados de en el sitio web del Proyecto Maven Apache
Dura realidad
Todo está bien y saludable, es hora de sentir una sensación de satisfacción, pero no. Resulta que este método no funcionará para la instalación y el despliegue, ya que no será reemplazado en las descripciones de los artefactos publicados en el repositorio. ${revisión} en su significado y maven ya no entenderá de qué se trata.
org.apache
apache
${revisión}
Una luz al final de un túnel
Necesitamos buscar una solución al problema. Podría haber salvado la situación. . Este complemento resuelve todas las variables en el pom, pero al mismo tiempo elimina mucha otra información que solo se necesita durante el ensamblaje y no se necesita al importar artefactos publicados a otros proyectos. El complemento también "rectifica" todas las dependencias entre padres e hijos y, como resultado, obtienes un pompón plano que incluye todo lo que necesitas. El inconveniente fue que elimina demasiado "extra", 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 Github en el repositorio de complementos con el deseo de hacerlo posible. para determinar por nuestra cuenta cómo "estropear" pom.xml. Los desarrolladores escucharon las voces de los que sufrían, y ya en diciembre, con el lanzamiento de la nueva versión 1.1.0, apareció un nuevo modo, resolveCiFriendliesOnly, en el complemento flatten-maven, que era más adecuado que nunca: deja pom.xml tal cual, excepto el elemento y permite ${revisión}, ${sha1} и ${lista de cambios}.
Agregar un complemento al proyecto
org.codehaus.mojo
complemento-aplanar-maven
1.1.0
verdadero
resolverCiFriendliesOnly
aplanar
recursos-proceso
aplanar
aplanar.limpiar
limpio
limpio
¡Ya está!
Final feliz
De ahora en adelante, para cambiar la versión de todo el proyecto y que todas las dependencias lo sepan, solo necesitamos editar el elemento.revisión> solo en la raíz pom.xml. A la revisión no llegan cien o dos de estos archivos con el mismo cambio, sino uno. Bueno, no es necesario usar versiones-maven-plugin.
Fuente: habr.com
