http://blog.ltgt.net/maven-is-broken-by-design/Concordando ou discordando, o texto e bom. No mundo maven, existem dois "tipos" de repositorios: o local (~/.m2/repository por padrao) e os remotos (por exemplo, maven central). Verdade seja dita, basicamente qualquer servidor pode se tornar um repositorio remoto, mas isso e meio tosco demais pro meu gosto.Vamos ao jeito decente.Se voce tem um open source, voce pode dar uma olhadinha em maven central. Se voce esta dentro de uma companhia, voce pode googlar por "maven artifact repository manager". Por exemplo, essa comparacao. Eu so tenho experiencia com o Nexus, e provavelmente a versao open source vai atender bem suas necessidades. Mas tome vergonha nessa cara e bote um Repository Manager dentro da tua companhia, nao faca gambiarras just because. (**)Entao digamos que voce configurou o seu ambiente e/ou projeto para tambem olhar esse novo repository manager (no seu settings.xml ou pom.xml). Isso quer dizer que, na hora de procurar dependencias faltantes, o maven ira olhar tambem 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. Voce, avido 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. Voce faz commit, seus coleguinhas tambem fazem uns "git pull", a vida parece linda e normal. Ate que alguma alma santa descobre um bug critico na tal versao 4.5, severo a ponto de causar falhas de segurancas gravissimas.E alguem tem a brilhante ideia de modificar o troco e fazer o redeploy. (***)Isto e, quem pegou a versao antiga do artefato, continuara usando a versao antiga. Quem ainda nao pegou, pegara a nova. Pessoas diferentes usarao artefatos diferentes. Lembre-se tambem dos agentes de build.... alguns vao ter versao nova, alguns antiga, bugs surgindo sabe-se la daonde, e uma versao 4.5 que significa nada.Situacao 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 informacoes no pom.xml, o desgracado dava informacoes diferentes dependendo se a pessoa tinha feito o download antes de mudar ou depois. Pior ainda se voce adicionar uma estrutura que possui cerca de 5 proxies espalhados pelo mundo.Quer a dica? Desapegue de numeros. E uma versao, um numero apenas. O plugin de release falha tantas vezes que o melhor mesmo e tratar isso como um numero sem o menor apego. Aceite.Queime quantos numeros forem necessarios. Mas nunca sobrescreva. ** Voces conhecem as regras. Se voce nao paga seus "tech debts", voce vai a falencia com os juros*** E verdade que se pode configurar o Nexus para nao aceitar redeploy, mas isso depende do seu tipo de build. Algumas limitacoes podem te impedir de configura-lo desse jeito. Um dia voce decide que quer que todo mundo que builda o seu projeto tem que usar maven 3.0.5Voce lembra que o maven tem um troco chamado "prerequisites", e pensa "uhuuu, vou colocar no meu parent pom." 3.0.5Seria genial e simples, ne? Ja pensou ainda se TODA sua empresa usa o mesmo parent pom. Pensa, forcar