Gerenciamento de dependências e builds com Maven 60

Maven é uma ferramenta utilizada no gerenciamento de dependências e builds do projeto. Pode ser utilizada em linguagens como: C#, Scala, Ruby, Java, entre outras. Sua instalação é bastante simples, basta fazer o download no formato .zip e descompacta-lo. Sendo que para ser utilizado via terminal é necessário configurar as variáveis de ambiente. É possível verificar a instalação do Maven com o comando: mvn –version. Esta ferramenta possui um arquivo de configuração chamado pom.xml (Project Object Model), que fica na raiz do projeto, é nele que se declara a estrutura, dependências e as características do projeto. A seguir é possível observar a estrutura básica de um arquivo pom.xml:

Figura 23 – Arquivo pom.

Nesse arquivo xml observa-se os seguintes elementos:

- groupId: identificador da empresa, instituição, normalmente o domínio ao contrário, no exemplo foi utilizado o domínio ao contrário da Unisul (www.unisul.br);

- artifactId: identificador único do projeto na empresa ou instituição; - version: a versão do projeto;

- packaging: tipo de empacotamento (jar, war, ejb...).

As funcionalidades do Maven podem ser estendidas utilizando plug-ins. Outra possibilidade da ferramenta é a geração de arquétipos (archetype), que é uma espécie de template, podendo ser utilizado em outros projetos.

Para se criar um novo projeto Maven via terminal, deve-se criar um novo diretório, e estando dentro desse diretório realizar o comando: mvn archetype:generate. Na imagem a seguir é possível visualizar uma série de arquétipos já existentes, nessa imagem 1160 arquétipos.

Figura 24 – Arquétipos disponíveis.

Fonte: O autor, 2014.

Neste exemplo será utilizado um arquétipo de projeto Java simples, para isso pode ser utilizado um filtro, digitando a palavra quickstart onde parou o cursor. Será exibido uma

série de versões, para esse exemplo foi escolhido a ultima versão, 1.1. Será solicitado que informe os elementos: groupId, artifactId, gerando automaticamente uma versão e sugerindo um pacote, de acordo com o groupId, como pode ser visto na imagem a seguir:

Figura 25 – Configuração projeto Maven.

Fonte: O autor, 2014.

Acessando o diretório verifica-se que foi criado um novo projeto Java com alguns sub-diretórios (src/main, src/test), bem como o arquivo pom, que pode ser visto a seguir:

Figura 26 – Arquivos pom gerado.

Fonte: O autor, 2014.

Verificando o arquivo gerado observa-se que o arquétipo escolhido já possui as dependências do JUnit, não necessitando fazer download de nenhum elemento adicional separadamente. Quando for iniciado ele fará o download das dependências declaradas no pom. O download é feito à partir de um repositório publico na web chamado repositório central do Maven, e adicionado a um repositório local na maquina, nas pasta do usuário, chamado .m2. Se a mesma dependência for requerida em um outro projeto, a busca será feita neste repositório local. Para que o download seja realizado de um repositório específico, é preciso fazer a declaração no arquivo pom. No exemplo foi adicionado também a tag scope, que informa em que fase o artefato será utilizado, neste caso na fase de teste.

Esta ferramenta possui um ciclo de vida, por vezes também chamado ciclo de build, neste ciclo uma série de etapas são realizadas. Na imagem a seguir é possível visualizar o ciclo de vida padrão do Maven, este ciclo pode sofrer alteração com a instalação de algum plugin.

Figura 27 – Fases do ciclo de vida Maven.

Fonte: Apache Maven Project, 2014.

Se for realizado um comando mvn:package, o Maven realizará todas as etapas anteriores até a fase package. A fase package gera um artefato, conforme declarado no arquivo pom. O Maven pode ser integrado a alguma IDE. Para o Eclipse a integração é realizada através do plugin m2eclipse, que deve ser instalado. Após instalado o plugin, é possível criar um novo projeto e inserir as dependências com o auxilio de uma interface gráfica. Na imagem a seguir foi criado um novo projeto Maven utilizando a IDE. Nesta imagem pode ser visto a exibição dos arquétipos disponíveis.

Figura 28 – Eclipse, arquétipos disponíveis.

Fonte: O autor, 2014.

Semelhantemente ao processo via terminal, na próxima interface é exibido formulário para inserção de groupId, artifactId... Ao final o projeto é criado, com a estrutura do arquétipo webapp, que pode ser visto a seguir:

Figura 29 – Estrutura do projeto Maven gerado.

Fonte: O autor, 2014.

A estrutura gerada é a de um arquétipo Maven webapp, outro arquétipo pode possui estrutura diferente.

Em projetos grandes e que possuam equipes grandes, é muito importante atentar para a padronização, desta forma é utilizado muitas vezes repositórios locais, específicos da empresa, nesses repositórios adiciona-se as dependências de projetos específicos da empresa, com as versões específicas. Outra vantagem da utilização de repositórios locais é não necessitar da web, já que esta rodando em um servidor local, na empresa. É neste repositório também onde são depositados os artefatos produzidos no projeto.

O Maven fornece uma série de relatórios, criados à partir da utilização de plugins declarados no arquivo pom. Estes relatórios apresentam informações de quanto do código fonte está coberto por testes, se há duplicidade de código, tamanho de classe, se é muito

longa, entre outros. Para estes relatórios regras podem ser criadas, como por exemplo: se a cobertura de testes no código for menor que 50% o build falhará. Essas regras são inseridas também no arquivo pom. Na imagem a seguir é apresentado o exemplo de um pequeno relatório com o plugin Jacoco, esse relatório mostra o quanto dos métodos está coberto por testes. Esta informação traz segurança para realizar alterações pois sabe-se quanto do método está todo coberto por testes.

Figura 30 – Relatório Jacoco.

Fonte: CodingByExample.org, 2014.

Na imagem observa-se os métodos com sua porcentagem do cobertura por testes. Diversos outros plug-ins existem para gerar outros tipos de relatórios também utilizando o Maven. Os relatórios na maioria das vezes são gerados em dois formatos, html e xml. A vantagem de ter o relatório em xml é que este pode ser exibido por uma outra ferramenta, como por exemplo o Jenkins, ferramenta que será apresentada a seguir.