O conto do artefato estável que foi "deployed" mais de uma vez

No mundo maven, existem dois "tipos" de repositórios: o local (~/.m2/repository por padrão) e os remotos (por exemplo, maven central). Verdade seja dita, basicamente qualquer servidor pode se tornar um repositório remoto, mas isso é meio tosco demais pro meu gosto.

Vamos ao jeito decente.

• Se você tem um open source, você pode dar uma olhadinha em maven central. 
• Se você está dentro de uma companhia, você pode googlar por "maven artifact repository manager". Por exemplo, essa comparação. Eu só tenho experiência com o Nexus, e provavelmente a versão open source vai atender bem suas necessidades. Mas tome vergonha nessa cara e bote um Repository Manager dentro da tua companhia, não faça gambiarras just because. (**)

Então digamos que você configurou o seu ambiente e/ou projeto para também olhar esse novo repository manager (no seu settings.xml ou pom.xml). Isso quer dizer que, na hora de procurar dependências faltantes, o maven irá olhar também esse servidor.


Um dia feliz no trabalho, e seu colega acabou de fazer release do artefato "com.mycompany.me:nice-artifact:4.5", e te avisa. Você, ávido pelas novas features, faz o upgrade no seu projeto.

<dependency>
    <groupId>com.mycompany.me</groupId>
    <artifactId>nice-artifact</artifactId>
-   <version>4.4</version>
+  <version>4.5</version>
</dependency>

Aparentemente tudo funciona, tudo lindo. Você faz commit, seus coleguinhas também fazem uns "git pull", a vida parece linda e normal. Até que alguma alma santa descobre um bug crítico na tal versão 4.5, severo a ponto de causar falhas de seguranças gravíssimas.

E alguém tem a brilhante idéia de modificar o troço e fazer o redeploy. (***)

Isto é, quem pegou a versão antiga do artefato, continuará usando a versão antiga. Quem ainda não pegou, pegará a nova. Pessoas diferentes usarão artefatos diferentes. Lembre-se também dos agentes de build.... alguns vão ter versão nova, alguns antiga, bugs surgindo sabe-se lá daonde, e uma versão 4.5 que significa nada.


Situação real: commons-io resolveu mover um jar de um groupId para outro. DEPOIS do release. O jar continuava o mesmo, mas obviamente o arquivo pom.xml mudava. Como eu tenho um plugin que olha informações no pom.xml, o desgraçado dava informações diferentes dependendo se a pessoa tinha feito o download antes de mudar ou depois. Pior ainda se você adicionar uma estrutura que possui cerca de 5 proxies espalhados pelo mundo.



Quer a dica? Desapegue de números. É uma versão, um número apenas. O plugin de release falha tantas vezes que o melhor mesmo é tratar isso como um número sem o menor apego. Aceite.
Queime quantos números forem necessários. Mas nunca sobrescreva.




** Vocês conhecem as regras. Se você não paga seus "tech debts", você vai à falência com os juros
*** É verdade que se pode configurar o Nexus para não aceitar redeploy, mas isso depende do seu tipo de build. Algumas limitações podem te impedir de configurá-lo desse jeito. 

SNAPSHOTs versions

Cada vez que vc faz "mvn install" numa versão que não é SNAPSHOT, essa é minha reação:

Gente, não. Não, não, não.


Uma versão estável, isso é, uma que não termina com "SNAPSHOT", é considerada imutável. IMUTÁVEL. Qualquer coisa que você esteja desenvolvendo obrigatoriamente tem que ser "SNAPSHOT".

O que isso significa?

Digamos que você está chamando o maven como de costume. Em qualquer projeto, mvn test.
O maven vai lá, procura todas as dependências. Se uma dependência não é SNAPSHOT, ele assume que, se já está no maven local repo (aquela pasta ~/.m2/repository), aquilo tá certo. Se você foi lesado de sobreescrever uma versão que NÃO É a correta, só deletando os arquivos pra consertar.

SNAPSHOT versions tem outro tratamento, mas fica pra outro post.


Opções:

• Usualmente você não precisa rodar "mvn install". Um "mvn verify" pode te salvar muitas vezes
• Se existir realmente motivo para recompilar uma versão já estável, use um outro maven local repo : "mvn -Dmaven.repo.local=$HOME/.my/other/repository install"
• Pra fazer release, use o plugin de release. Ajuda com tag, com pom file, com deploy.
• Ok, esse plugin de release é a besta do apocalypse em forma de plugin, você pode dar uma olhada no git-workflow plugin.

Mudança de planos

Eu tenho esse blog desde guaraná com rolha, e sinceramente, a idéia é boa mas eu nunca me policiei.

Mudei de vida, larguei das dorga, agora não mexo mais com essas paradas de apresentação.


Sou devops.  (#sóQueNão)
Em tempo: http://devopsreactions.tumblr.com/


Em tempo 2: sou ruiva, mas não tenho habilidade nem pra pintar a bonequinha no paint.

Em tempo 3: foda-se, o blog é meu, eu faço ele tão "girlie" quanto eu quero.