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.