Gerenciando seus artefatos com o Nexus

Já há alguns anos no mercado, o Apache Maven trouxe vários benefícios aos projetos Java, desde aqueles de pequeno porte aos projetos Java EE. Através de um conjunto extenso de plugins pré-existentes, um novo script de build pode ser criado rapidamente, sem toda a complexidade de tempos anteriores. Outro benefício da ferramenta vem dos conceitos de artefatos e repositórios, que serão apresentados adiante. Entretanto, este modelo de build traz alguns desafios organizacionais que podem ser resolvido com ajuda do Nexus, como veremos neste post.

Artefatos são itens quaisquer (jars, ears, wars, zips, …), em geral produzidos por scripts de build e que, segundo as convenções definidas pelo Maven, possuem identificadores únicos formados pelo seu groupId, arfifactId, e version, como no exemplo abaixo:

<dependency>

<groupId>commons-collections</groupId>

<artifactId>commons-collections</artifactId>

<version>3.1</version>

</dependency>

Os repositórios, por sua vez, tratam-se de servidores onde estes artefatos são armazenados e podem ser posteriormente localizados por um processo Maven. O repositório mais conhecido é o Maven Central, mas existem outras dezenas disponíveis na web. Unindo estes dois conceitos, o Maven permite que um projeto declare em seu arquivo de configuração (pom.xml) todos os artefatos de que depende, bem como os repositórios onde eles deverão ser buscados:

<repository>

<id>central</id>

<url>http://repo1.maven.org/maven2</url>

</repository>


Uma das vantagens desta declaração é a economia de espaço no servidor de código fonte, já que não precisamos salvar as bibliotecas das quais dependemos junto do código, o que em projetos Java EE pode representar um volume grande de arquivos.

Esta forma de trabalho, entretanto, traz duas questões importantes:

A primeira diz respeito aos artefatos privados gerados por uma empresa. Definitivamente não queremos que sejam disponibilizados em um servidor público, mas precisamos de uma forma de utilizá-los no Maven. A segunda questão é o consumo de banda. Com os repositórios na web, é necessário que cada desenvolvedor faça download de todos os artefatos para sua estação de trabalho.

Para ambas as questões, podemos utilizar o Sonatype Nexus como solução.

O Nexus é uma ferramenta bastante conhecida no mundo Java. Sua função é permitir cadastrar repositórios Maven de dois tipos:

Repositórios hosted são aqueles em que os artefatos são armazenados localmente no servidor onde o Nexus foi instalado. Este tipo de repositório é utilizado para que projetos possam publicar internamente seus artefatos. Pode-se inclusive configurar o arquivo pom.xml do seu projeto para que faça deploy automaticamente no Nexus, até mesmo por um servidor de builds, como o Jenkins ou TeamCity, utilizando a tag <distributionManagement>.

No exemplo a seguir, estamos configurando 2 repositórios para deploy, cada um com sua url. No caso, artefatos do tipo SNAPSHOT são enviados para o repositório nexus-snapshots, enquanto artefatos com versão cheia são enviados para o nexus-releases.

<distributionManagement>

<repository>

<id>nexus-releases</id>

<name>nexus-releases</name>

<url>http://myserver:8080/nexus/content/repositories/releases</url>

</repository>

<snapshotRepository>

<id>nexus-snapshots</id>

<name>nexus-snapshots</name>

<url>http://myserver:8080/nexus/content/repositories/snapshots</url>

</snapshotRepository>

</distributionManagement>


O Nexus já vem com 3 repositórios hosted pré-configurados: Releases, Snapshots e 3rd party.

Com este recurso, outros projetos podem adicionar o servidor Nexus corporativo ao seu pom.xml como repositório, resolvendo a questão do compartilhamento de artefatos.

<repository>

<id>nexus</id>

<name>nexus</name>

<url>http://myserver:8080/nexus/content/groups/public</url>

</repository>

 O segundo tipo de repositório é chamado de proxy. Como o nome sugere, são repositórios que atuam como intermediários para outros repositórios na web, fazendo cache dos artefatos.

Veja um exemplo de configuração para o Maven Central:

central

Note que neste caso apenas configuramos a url do repositório remoto.

Podemos configurar o projeto para uso do Nexus como repositório, pois assim, as tentativas de resolução dos artefatos serão feitas inicialmente no cache, e só em caso de falha, o servidor remoto será de fato acessado, resolvendo a questão do consumo excessivo de banda.

E, finalmente, para que não seja necessário configurar cada repositório do Nexus como um repositório no pom.xml, podemos criar um agrupador no próprio Nexus, um repositório Virtual. Através deste agrupador, criamos uma url única a ser configurada nos poms, e que faz a busca em todos os repositórios.

O Nexus já vem com um repositório virtual pré-instalado, chamado Public Repositories. Basta adicionar os repositórios proxy e hosted ao mesmo para que fiquem disponíveis através de uma url única:

public

Através destes conceitos iniciais, já conseguimos melhorar bastante a organização de nossos projetos. O Nexus possui ainda várias configurações para otimização, mecanismos de alerta, expurgo automático de artefatos, e controle de acesso bem refinado. Instalando a ferramenta e conhecendo suas configurações básicas, pode-se partir para um refinamento dos parâmetros de forma que melhor se adapte ao seu ambiente.

Por LUIS SERGIO F. CARNEIRO

Postado em: 31 de julho de 2013

Confira outros artigos do nosso blog

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

Three laws that enable agile software development

09 de março de 2017

Celso Gonçalves Junior

Medindo performance de uma API REST

21 de fevereiro de 2017

Monise Costa

Deixe seu comentário