Quen somos
En 1C desenvolvemos non só unha 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
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
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
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