Sobre nós
Na 1C, desenvolvemos não apenas a plataforma para e , mas também aplicativos em Java – em particular, um novo ambiente de desenvolvimento baseado no Eclipse e um servidor profundamente integrado com a plataforma de mensageiro – .
Introdução
Como sistema de construção de aplicativos Java, costumamos usar o maven, e neste pequeno artigo gostaríamos de falar sobre um dos problemas que encontramos durante a organização do desenvolvimento e a abordagem que nos permitiu superá-lo.
Pressupostos e Fluxo de Trabalho
Devido à especificidade do desenvolvimento em nossos projetos maven, usamos um número considerável de módulos, dependências e projetos filhos. O número de arquivos pom em uma árvore pode somar dezenas e até centenas.
À primeira vista: não há nada de aterrador, criamos uma vez e esquecemos. Se precisar mudar ou adicionar algo em todos os arquivos de uma vez, existem muitas ferramentas convenientes em editores e IDEs. E qual é a alteração mais comum do pom.xml? Acreditamos que seja a mudança das versões dos projetos e das dependências. Talvez alguém queira discutir isso, mas é assim que as coisas estão para nós. A razão está no fato de que, junto com o núcleo, desenvolvemos paralelamente muitas bibliotecas próprias, e para garantir a reprodutibilidade contínua dos resultados de construção e teste, o uso de snapshots não é um método conveniente para nós. Por essa razão, somos obrigados a aumentar o número da versão nos projetos a cada construção.
Além disso, o desenvolvedor de vez em quando precisa compilar seu ramo de alguma biblioteca e testar sua funcionalidade em todas as dependências, para isso é necessário mudar manualmente a versão em todas elas.
Solução Inicial
Com tantas mudanças frequentes e múltiplas nas versões, o processo dentro do CI gostaria de simplificar e automatizar. Aqui entra em cena um plugin conhecido e conveniente versions-maven-plugin – o conectamos e executamos
mvn -N versions:set -DnewVersion=2.0.1
e o maven fará tudo certinho: percorrerá a hierarquia de cima para baixo, mudará todas as versões – lindo! Agora só falta levantar um pull request, os colegas revisarão as mudanças, e podemos rapidamente nos integrar ao trunk. Rapidamente? Como se não fosse assim. Um par ou três centenas pom.xml em revisão, e isso sem contar o código. Além disso, ninguém está imune a conflitos de merge com um número tão grande de arquivos alterados. É importante notar que, durante o CI, as mudanças de versão ocorrem automaticamente junto com a alteração da funcionalidade, e não de forma separada.
Novas funcionalidades
Por um tempo, nos acalmamos e, resignados, vivemos assim, até que os caras do incluíram no maven, a partir da versão 3.5.0-beta-1, o suporte para os chamados 'substitutos' de versões (placeholders). A essência desses substitutos é que em pom.xml vez de uma indicação específica da versão do projeto, são utilizadas variáveis ${revision}, ${sha1} e ${changelist}. Os próprios valores dessas propriedades são definidos either no elemento <properties>, ou podem ser definidos através da propriedade do sistema
mvn -Drevision=2.0.0 clean package
Os valores das propriedades do sistema têm prioridade sobre os valores definidos em <properties>.
Pai
<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>First CI Friendly<\/name>
<version>${revision}${sha1}${changelist}<\/version>
…
<properties>
<revision>1.3.1<\/revision>
<changelist>-SNAPSHOT<\/changelist>
<sha1\/>
<\/properties>
<\/project>
Filho
<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>
Se quisermos compilar a versão 2.0.0-SNAPSHOT, basta usarmos
mvn -Drevision=2.0.0 clean package
Se quisermos fazer um release, simplesmente zeramos o SNAPSHOT
mvn -Dchangelist= clean package
*Os exemplos acima são retirados de no site do Maven Apache Project
A dura realidade
Tudo está bem e maravilha, é hora de experimentar a satisfação, mas não. Aparentemente, para install e deploy, esse método não funcionará, pois nas descrições dos artefatos publicados no repositório não será feita a substituição ${revision} pelo seu valor e o maven não entenderá do que se trata.
<parent>
<groupId>org.apache<\/groupId>
<artifactId>apache<\/artifactId>
<version>${revision}<\/version>
<\/parent>
Luz no fim do túnel
É preciso procurar uma solução para o problema. A situação poderia ser salva por Este plugin permite todas as variáveis no pom, mas ao mesmo tempo corta uma tonelada de outras informações que só são necessárias durante a construção e não são necessárias ao importar artefatos publicados em outros projetos. Além disso, o plugin "niveliza" todas as dependências parent-child, resultando em poms planos, que incluem tudo o que é necessário. O problema era que ele cortava "demais", o que não nos agradava. Depois de estudar informações sobre o desenvolvimento deste plugin, descobrimos que não éramos os únicos no universo e que já em agosto de 2018, no GitHub, um pull-request foi criado no repositório do plugin com o desejo de permitir a definição de como "mudar" o pom.xml. Os desenvolvedores ouviram as vozes dos clamantes, e já em dezembro, com o lançamento da nova versão 1.1.0, surgiu um novo modo resolveCiFriendliesOnly no flatten-maven-plugin, que veio a calhar – ele mantém o pom.xml como está, exceto pelo elemento <version> e permite ${revision}, ${sha1} e ${changelist}.
Adicionar o plugin ao projeto
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.1.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
<flattenMode>resolveCiFriendliesOnly</flattenMode>
</configuration>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Pronto!
Final feliz
A partir de agora, para mudar a versão de todo o projeto e informar todas as dependências, precisamos apenas editar o elemento <revision> em apenas um único raiz pom.xml. Desta forma, ao revisar, não recebemos centenas desses arquivos com a mesma alteração, mas um só. E a necessidade de usar versions-maven-plugin.
Fonte: habr.com
