Estabilidade do build utilizando o Maven

Maven: A person who has special knowledge or experience; an expert.

O Maven é uma ferramenta de build fantástica. Não é perfeita, pois como estamos cansados já de discutir, não existe esse conceito de ferramenta, linguagem etc perfeito. Contudo eu particularmente considero que 95% das pessoas que reclamam do maven é porque não sabem utilizá-lo. Os outros 5% talvez tenham razão.

Algo que contribui e muito para as reclamações sobre o maven são a infinidade de poms de dependências mal feitos (provavelmente criados pelos 95%). Infelizmente, eles são muito mais comuns do que o tolerável.

Outro problema crítico para qualquer equipe de software é a estabilidade do build. O maven "baixa" as suas dependências através da Internet - por padrão através de repositórios públicos. Se o seu projeto é "novo", sem problemas. As dependências estarão lá. O problema é garantir que estas mesmas dependências estarão presentes daqui a 2, 3, 5 ou 10 anos. O que aconteceria se alguém resolvesse "apagar" aquelas dependências (já que os repositórios são controlados por terceiros, e não por você)? Resultado: build quebrado.

Para nossa sorte há uma categoria de software que resolve os "problemas" do maven acima citados: os gerenciadores de repositório. Nesta categoria enquadram-se o Nexus e o Artifactory. O Nexus é mais antigo, e tenho trabalhado já há um bom tempo com ele. O Artifactory é mais recente e em 2011 ganhou um Duke Award da Oracle. Algumas comparações baseadas na minha experiência:

• O Nexus, por ser mais antigo, é mais popular. O repositório central do próprio maven passou a utilizá-lo recentemente. O mecanismo de busca do repositório central do maven utiliza-o (Obrigado ao @aldrinleal pela correção!)
• O Nexus possui um consumo de memória menor. O heap da minha instalação é de 64MB. No site do Artifactory recomenda-se 300MB.
• O Artifactory é transacional. Isso faz com que qualquer atualização dos repositórios seja bem sucedida ou não sucedida. Não há estado inconsistente - que (dizem, não sou testemunha) ocorre com o Nexus (o Nexus utiliza somente arquivos).
• O Nexus utiliza somente o sistema de arquivos. O Artifactory precisa de um banco de dados (por ser transacional).
• O Nexus armazena cópias repetidas do mesmo arquivo que existem em repositórios diferentes. O Artifactory armazena somente uma e a referencia em repositórios diferentes (menor consumo de espaço).

Ambos funcionam bem. Escolher um ou outro passa a ser uma questão de gosto. O importante é escolher um e utilizá-lo. Mas como estes gerenciadores resolvem o problema do maven?

• Se há um pom.xml mal feito num repositório público, você mesmo pode corrigi-lo e fazer o upload no seu Nexus ou Artifactory. Assim, os seus projetos utilizarão o seu pom.xml corrigido. Claro que você pode e deve contribuir sua correção para os autores de um projeto livre, mas se eles irão aceitar suas "correções" depende deles, e não de você.
• O Nexus ou o Artifactory realizam o download das suas dependências de repositórios externos e as salvam em seu repositório privado. Desse modo, mesmo que alguém desapareça com o repositório central do maven, ao menos as dependências do seu projeto estarão seguras no seu repositório local, garantindo a estabilidade do seu build.

Conclusão? Qualquer equipe de software consciente que trabalhe com o maven tem que utilizar um gerenciador de repositório. Escolha o seu.