Artigos Java Gerencie repositórios com Archiva
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Conteúdo sobre boas práticas.
Gerencie repositórios com Archiva
Este artigo apresenta o Apache Archiva, uma ferramenta que funciona como um proxy para o repositório central do Apache Maven e de outros fornecedores. O Archiva facilita a gestão de repositórios e dependências ao centralizar a administração de repositórios e o versionamento de componentes.


Em que situação o tema é útil
Este tema é útil para desenvolvedores e projetistas que desejam conhecer uma opção de como centralizar a administração de repositórios e dependências utilizadas pelo Apache Maven. Neste artigo será abordado como esta ferramenta, o Apache Archiva, pode facilitar a gerência de dependências que o Maven solicita para a geração de artefatos.

Muitos desenvolvedores utilizam o Apache Maven para configurar um ambiente de desenvolvimento padronizado e gerenciar a construção (processo conhecido como build) de artefatos como Java ARchive (JAR), Web ARchive (WAR), Enterprise ARchive (EAR), entre outros.

Em linhas gerais, o Maven utiliza arquivos conhecidos por Project Object Model (POM) para obter informações sobre o projeto e detalhes de configurações que serão utilizadas durante o processo de construção.

Dependendo das configurações feitas no POM, o Maven pode necessitar de outras dependências para a realização do processo de construção. Quando necessário, ele consulta seu repositório padrão e outros repositórios que eventualmente estejam em suas configurações, assim viabilizando o processo de construção.

Apesar desta vantagem, esta prática pode ocasionar um descontrole nos repositórios utilizados para a construção, pois cada desenvolvedor pode configurar em seu sistema quais repositórios irá utilizar. Além disso, mesmo que todos os desenvolvedores optem pelos mesmos repositórios para encontrar dependências, a necessidade de adicionar ou atualizar um repositório deve ser garantida para toda equipe que adota o Maven. Isto demandaria a atualização do arquivo pom.xml e/ou settings.xml de todos os desenvolvedores. Talvez em grupos reduzidos de desenvolvedores esta atualização possa ser viável, mas em grandes departamentos de desenvolvimento pode se tornar complexo.

Nestas situações, talvez seja mais interessante centralizar a busca de dependências em um único local. Deste modo, para o Maven, existiria apenas um local para encontrar as dependências. Mas este local, por sua vez, poderia buscar por dependências em diversos repositórios para a construção dos artefatos.

Em outras palavras, para os desenvolvedores ficaria transparente onde suas dependências estão sendo resolvidas, pois para eles existiria apenas um local central, e este por sua vez realizaria as consultas em diversos outros repositórios.

Este é o papel do Apache Archiva, servir como um gerenciador central para administração de repositórios e dependências para a construção (builds) de artefatos de maneira organizada, separada por versões e num ambiente controlado.

Apesar de o Apache Archiva trabalhar em conjunto com o Maven, neste artigo não nos aprofundaremos no Maven, pois o intuito é conhecer como instalar e configurar o Archiva para ser acessado através do Tomcat.

Funcionamento do Apache Archiva

Para entender melhor os benefícios do Archiva, vamos primeiramente entender, em linhas gerais, como o Maven realiza o processo de construção de componentes. Na Figura 1 podemos visualizar as etapas até a construção do componente final (JAR / WAR / EAR).

abrir imagem em nova janela

Figura 1. Processo de construção de componentes no Maven.

Analisemos passo a passo as etapas descritas na Figura 1:

1. Empacotamento: O desenvolvedor invoca o Maven para montar e empacotar seu(s) projeto(s). O Maven, por sua vez, utilizará o(s) arquivo(s) POM para identificar as dependências necessárias para a compilação (compile) e empacotamento (package);

2. Repositório local: Por padrão, o Maven irá tentar recuperar as dependências em um repositório local, que geralmente está localizado na própria estação de trabalho do desenvolvedor;

3. Repositório Remoto: Quando o Maven não encontra a(s) dependência(s) necessária(s) localmente, então ele fará acesso(s) ao seu repositório remoto e copia as dependências para o repositório local;

4. Empacotamento: Com a(s) dependência(s) resolvida(s), o Maven poderá compilar e empacotar o(s) projeto(s).

Olhando para este modelo, poderíamos nos questionar:

· Como centralizar a administração dos repositórios remotos onde todos os desenvolvedores poderiam resolver suas dependências?

· Como criar um repositório corporativo na intranet onde fosse possível colocar as versões das dependências, evitando assim o tráfego remoto de rede?

· Como disponibilizar dependências criadas corporativamente para uso interno?

...

Quer ler esse conteúdo completo? Tenha acesso completo