Experiência usando o flatten-maven-plugin para simplificar a versão em projetos maven

Sobre nós

No 1C, desenvolvemos não apenas a plataforma 1C: Enterprise em C ++ e JavaScript , mas também aplicativos Java - em particular, o novo ambiente de desenvolvimento de Ferramentas de Desenvolvimento Empresarial baseado no Eclipse e um servidor profundamente integrado à plataforma de mensagens instantâneas - Interaction Systems .

Entrada

Na maioria das vezes, usamos o maven como o sistema para montar aplicativos Java e, neste pequeno artigo, gostaríamos de falar sobre um dos problemas com os quais tivemos que lidar durante o processo de desenvolvimento e a abordagem que nos permitiu superar esse problema.

Histórico e fluxo de trabalho

Devido às especificidades do desenvolvimento em nossos projetos, usamos muitos módulos, dependências e projetos filhos. O número de arquivos pom em uma árvore pode ser dezenas ou mesmo centenas.



Parece: tudo bem, uma vez criado e esquecido. Se você precisar alterar ou adicionar algo em todos os arquivos de uma só vez, existem muitas ferramentas convenientes em editores e IDEs. E qual é a alteração regular mais comum no pom.xml? Acreditamos que a alteração das versões e dependências do projeto. Talvez alguém queira discutir isso, mas é esse o caso conosco. A razão é que, juntamente com o kernel, estamos desenvolvendo simultaneamente muitas de nossas próprias bibliotecas e, para a reprodutibilidade constante dos resultados de montagem e teste, o uso de snapshots não nos parece uma abordagem conveniente. Por esse motivo, é necessário aumentar o número da versão nos projetos em cada montagem.

Além disso, o desenvolvedor de tempos em tempos é necessário coletar sua ramificação de uma biblioteca e verificar seu desempenho em todas as dependências, para as quais todas elas precisam alterar manualmente a versão.

Decisão inicial

Com essas mudanças de versão frequentes e múltiplas, o processo dentro do IC quer ser simplificado e automatizado. Aqui o conveniente e conhecido plugin de versões maven-plugin vem em socorro - nós o conectamos e executamos

mvn -N version: set -DnewVersion = 2.0.1

e o Maven fará tudo como deve: percorrer a hierarquia de cima para baixo, substituir todas as versões - beleza! Agora resta aumentar a solicitação de recebimento, os colegas acompanharão as alterações e você poderá entrar rapidamente no tronco. Rapidamente? Não importa como. Algumas centenas de pom.xml por revisão, e isso não está contando o código. Além disso, ninguém está seguro contra conflitos de mesclagem com um número tão grande de arquivos modificados. Deve-se observar aqui que, durante o processo do IC, as alterações de versão ocorrem automaticamente, juntamente com uma alteração na funcionalidade, e não de alguma forma separadamente.

Novos recursos

Por um tempo, nos acalmamos e vivemos em paz, até que os caras do Maven Apache Project incluíam no maven, começando na versão 3.5.0-beta-1, suporte para os chamados "espaços reservados" das versões (espaços reservados). A essência desses substitutos é que as variáveis $ {revision} , $ {sha1} e $ {changelist} são usadas no pom.xml em vez de especificar a versão do projeto. Os próprios valores dessas propriedades são configurados no elemento < properties > ou podem ser definidos através da propriedade do sistema

mvn -Drevision = 2.0.0 pacote limpo

Os valores das propriedades do sistema têm precedência sobre os valores definidos em < properties >.

O pai
<projeto>
<modelVersion> 4.0.0 </modelVersion>
<pai>
<groupId> org.apache </groupId>
<artifactId> apache </artifactId>
<versão> 18 </ versão>
</parent>
<groupId> org.apache.maven.ci </groupId>
<artifactId> ci-pai </artifactId>
<name> Primeiro IC amigável </name>
<versão> $ {revision} $ {sha1} $ {changelist} </version>
...
<propriedades>
<revision> 1.3.1 </revision>
<changelist> -SNAPSHOT </changelist>
<sha1 />
</properties>
</project>

Descendente
<projeto>
<modelVersion> 4.0.0 </modelVersion>
<pai>
<groupId> org.apache.maven.ci </groupId>
<artifactId> ci-pai </artifactId>
<versão> $ {revision} $ {sha1} $ {changelist} </version>
</parent>
<groupId> org.apache.maven.ci </groupId>
<artifactId> ci-child </artifactId>
...
</project>


Se você deseja criar a versão 2.0.0-SNAPSHOT, basta usar

mvn -Drevision = 2.0.0 pacote limpo

Se você quiser fazer um lançamento, basta zerar SNAPSHOT

mvn -Dchangelist = pacote limpo

* Os exemplos acima foram retirados de um artigo no site do Maven Apache Project

Realidade dura

Tudo é bom e saudável, é hora de experimentar uma sensação de satisfação, mas não. Acontece que para instalar e implantar esse método não funcionará, porque $ {revision} não será substituído por seu valor nas descrições de artefatos publicados no repositório e o maven não entenderá o que é isso.

<pai>
<groupId> org.apache </groupId>
<artifactId> apache </artifactId>
<versão> $ {revisão} </ versão>
</parent>

Luz no fim do túnel

Devemos procurar uma solução para o problema. A situação poderia ter sido salva por um plugin flatten-maven . Esse plug-in permite todas as variáveis ​​no pom, mas, ao mesmo tempo, elimina uma tonelada de outras informações necessárias apenas durante a montagem e não são necessárias ao importar artefatos publicados para outros projetos. Além disso, o plug-in "endireita" todas as dependências pai-filho e, como resultado, obtemos um pom pom, que inclui tudo o que você precisa. O inconveniente foi que ele cortou "demais" demais, o que não serviu para nada. Depois de estudar as informações sobre o desenvolvimento deste plugin, verificou-se que não somos os únicos no universo e, em agosto de 2018, uma solicitação de pull foi criada no github no repositório de plugins com o desejo de tornar possível determinar independentemente como "estragar" o pom.xml. Os desenvolvedores ouviram as vozes dos aflitos, e já em dezembro, com o lançamento da nova versão 1.1.0, um novo modo resolveCiFriendliesOnly apareceu no plugin flatten-maven, que, como nunca antes - deixa o pom.xml como está, exceto o elemento <version> e permite $ {revisão} , $ {sha1} e $ {changelist} .

Adicionar um plugin ao projeto

<plugins>
<plugin>
<groupId> org.codehaus.mojo </groupId>
<artifactId> aplainar-maven-plugin </artifactId>
<versão> 1.1.0 </ versão>
<configuração>
<updatePomFile> true </updatePomFile>
<flattenMode> resolveCiFriendliesOnly </flattenMode>
</configuration>
<execuções>
<execução>
<id> achatar </id>
<phase> recursos do processo </phase>
<objetivos>
<goal> achatar </goal>
</goals>
</execution>
<execução>
<id> flatten.clean </id>
<phase> limpo </phase>
<objetivos>
<goal> limpo </goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>


Feito!

Final feliz

A partir de agora, para alterar a versão de todo o projeto e informar todas as dependências, basta editar o elemento < revision > em apenas uma raiz pom.xml . Não são cem ou dois desses arquivos com a mesma alteração que aparece na revisão, mas um. Bem, não há necessidade de usar o plugin versões-maven .