Quen somos
En 1C desenvolvemos non só unha plataforma en и , pero tamén aplicacións Java, en particular o novo entorno de desenvolvemento baseado en Eclipse e nun servidor de mensaxería profundamente integrado coa plataforma - .
Entrada
Usamos a maioría das veces maven como sistema de compilación para aplicacións Java, e neste breve artigo gustaríanos falar dun dos problemas aos que nos tivemos que enfrontar no proceso de organización do desenvolvemento, e do enfoque que nos permitiu superar isto. problema.
Requisitos previos e fluxo de traballo
Debido ás especificidades do desenvolvemento dos nosos proxectos maven, usamos bastantes módulos, dependencias e proxectos fillos. O número de ficheiros pom nunha árbore pode ser de decenas ou mesmo centos.
Parece: non é gran cousa, creárono unha vez e esquecéronse. Se precisas cambiar ou engadir algo en todos os ficheiros á vez, hai moitas ferramentas convenientes nos editores e IDE. Cal é o cambio regular máis común a pom.xml? Cremos que os cambios nas versións do proxecto e nas dependencias. Quizais alguén queira discutir con isto, pero esta é exactamente a situación que temos. A razón reside no feito de que, xunto co núcleo, estamos desenvolvendo simultaneamente moitas das nosas propias bibliotecas e, para a reproducibilidade constante dos resultados de compilación e proba, o uso de instantáneas non nos parece un enfoque conveniente. Por este motivo, é necesario aumentar o número de versión nos proxectos con cada compilación.
Ademais, de cando en vez, un desenvolvedor necesita construír a súa propia rama dunha biblioteca e comprobar a súa funcionalidade con todas as dependencias, para o que ten que cambiar manualmente a versión de todas elas.
Solución inicial
Con cambios de versión tan frecuentes e múltiples, quero simplificar e automatizar o proceso dentro de CI. Aquí é onde un complemento cómodo e coñecido vén ao rescate. versións-maven-plugin - conéctao e lánzao
versións mvn -N:set -DnewVersion=2.0.1
e Maven fará todo como debe: percorrerá a xerarquía de arriba a abaixo, substituíndo todas as versións: beleza! Agora só queda facer unha solicitude de extracción, os compañeiros revisarán os cambios e podes unirte rapidamente ao tronco. Axiña? Non importa como sexa. Un par de centos pom.xml para revisión, e isto non está a contar o código. Ademais, ninguén está a salvo de conflitos de fusión cunha cantidade tan grande de ficheiros modificados. Cómpre sinalar aquí que no proceso CI, os cambios de versión ocorren automaticamente xunto cos cambios na funcionalidade, e non por separado.
Novas funcións
Durante un tempo calmamos e, resignados, vivimos así ata que os rapaces de A partir da versión 3.5.0-beta-1, Maven non incluíu soporte para os chamados "marcadores de posición". A esencia destes substitutos é iso pom.xml en lugar dunha indicación específica da versión do proxecto, utilízanse variables ${revisión}, ${sha1} и ${changelist}. Os valores destas propiedades en si están definidos no elementoPropiedades>, ou poden definirse mediante unha propiedade do sistema
mvn -Drevision=2.0.0 paquete limpo
Os valores das propiedades do sistema teñen prioridade sobre os valores definidos enPropiedades>.
Pais
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-pai
Primeiro CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
- INSTANTÁNEA
Descendente
4.0.0
org.apache.maven.ci
ci-pai
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-neno
...
Se queres crear a versión 2.0.0-SNAPSHOT, simplemente usa
mvn -Drevision=2.0.0 paquete limpo
Se queres facer un lanzamento, simplemente restablece SNAPSHOT
mvn -Dchangelist= paquete limpo
*Os exemplos anteriores están tirados de no sitio web do proxecto Maven Apache
Cruda realidade
Todo é bo e saudable, é hora de sentir unha sensación de satisfacción, pero non. Resulta que este método non funcionará para instalar e despregar, xa que non será substituído nas descricións de artefactos publicadas no repositorio ${revisión} sobre o seu significado e o experto xa non entenderá de que se trata.
org.apache
apache
${revisión}
Unha luz ao final dun túnel
Temos que buscar unha solución ao problema. Podería salvar a situación . Este complemento resolve todas as variables do pom, pero ao mesmo tempo elimina moita outra información que só é necesaria durante a montaxe e que non é necesaria ao importar artefactos publicados noutros proxectos. O complemento tamén "endereita" todas as dependencias entre pais e fillos e, como resultado, obtén un pom plano que inclúe todo o que necesitas. O inconveniente foi que recorta demasiado “extra”, que non nos cabía nada. Despois de estudar a información sobre o desenvolvemento deste complemento, resultou que non somos os únicos no universo, e xa en agosto de 2018, creouse unha solicitude de extracción en Github no repositorio de complementos co desexo de facelo posible. para determinar pola nosa conta como "estragar" pom.xml. Os desenvolvedores escoitaron as voces dos que sofren e xa en decembro, co lanzamento da nova versión 1.1.0, apareceu un novo modo, resolveCiFriendliesOnly, no complemento flatten-maven, que era máis axeitado que nunca. pom.xml tal e como está, excepto o elemento e permite ${revisión}, ${sha1} и ${changelist}.
Engadindo un complemento ao proxecto
org.codehaus.mojo
flatten-maven-plugin
1.1.0
verdade
resolverCiFriendliesOnly
aplanar
procesos-recursos
aplanar
aplanar.limpar
limpar
limpar
Feito!
Fin feliz
A partir de agora, para cambiar a versión de todo o proxecto e que todas as dependencias saiban sobre iso, só necesitamos editar o elementorevisión> só na raíz pom.xml. Non chegan á revisión cen ou dous destes ficheiros co mesmo cambio, senón un. Ben, non hai necesidade de usar versións-maven-plugin.
Fonte: www.habr.com
