Automatizando tarefas com Maven ou Gradle

O processo de desenvolvimento de software exige, por parte da equipe envolvida, muita disciplina e organização. Independente de o software ser construído por uma ou mais pessoas, todas as tarefas que envolvem o processo de desenvolvimento necessitam de coordenação, para que ao final, tenha-se o produto e sua construção transcorrida de maneira correta. Por mais que seja estudada a engenharia de software, tendo como referências renomados autores como Roger Pressman ou Ian Sommerville, diversos fatores, como prazos, às vezes impedem de conduzir etapas deste processo como sugerem os especialistas. Infelizmente, ainda é comum desenvolvedores ignorarem etapas de testes de unidade. Com o “pulo” desta etapa, quando gerada uma versão beta para demonstração ao cliente, na hora da demonstração, é praticamente certo de o sistema falhar em algum ponto.

Quando o aprendizado de uma linguagem ou plataforma de desenvolvimento é iniciado, normalmente a primeira implementação é o famoso “Hello, world!”. É a partir deste pequeno exemplo que ocorre o aprofundamento do interesse e conhecimento nos aspectos técnicos da linguagem em estudo.

É possível então exemplificar, de uma forma simples, que entre o requisito do sistema ao aplicativo executável, têm-se as tarefas: codificação, testes, compilação, mais testes, e o release funcionando. Claro que existem muitas outras, mas do ponto de vista da materialização dos requisitos em um executável binário, essas talvez sejam indispensáveis e sempre presentes no processo. Mas como realizar estas “simples” tarefas no dia a dia? Será que se está codificando, testando, compilando e distribuindo as aplicações da melhor forma?

O build

É possível conceituar, de maneira simplista, um build como uma das tarefas mais importantes no processo de desenvolvimento de software, pois é ela quem constrói a aplicação, juntando todos os componentes do projeto. Após esta etapa, o aplicativo pode ser distribuído na forma de release. É comum se ouvir (ainda) que se não existirem erros na codificação, certamente o build não quebrará. Esta é uma informação falsa, pois nem sempre os erros acontecerão apenas sintaticamente. Na maioria das vezes, erros semânticos ou durante a integração com partes do sistema já construídas, podem sim quebrar o build.

Com isso, pode-se afirmar então que um projeto não pode ser visto apenas como aquelas simples etapas mencionadas anteriormente. É preciso entendê-lo como um artefato extremamente importante, “robusto” e com complexidades no que se refere ao gerenciamento, manutenção e evolução.

O build é uma tarefa determinante e não pode ser interpretada apenas como uma atividade de compilação de código fonte. É uma tarefa que deve ser construída por um membro da equipe com experiência em arquitetura de desenvolvimento de software, e que posteriormente pode ser executada de diferentes formas, automatizadas ou por pessoas.

É comum, para usuários do sistema operacional Linux, utilizar aplicativos que são construídos (build) na própria máquina e depois instalados. Estes profissionais comumente baixam o código fonte de um aplicativo e depois se utilizam de ferramentas como make e make install, para então, de fato, utilizar este aplicativo em seu computador. Estas ferramentas normalmente automatizam o processo de build do código fonte. Esta automatização comumente é escrita em linguagens como C, Python, Perl, ou outra qualquer, gerando assim os arquivos binários (executáveis). Para quem já teve a experiência com isso percebeu que, às vezes, de uma versão do sistema operacional para outra, o mesmo aplicativo requer dependências distintas, e este gerenciamento de dependências também pode ser controlado dentro do processo de build.

Deste modo, um projeto Java, independente do seu grau de complexidade ou tamanho, não tem as atividades de desenvolvimento concentradas apenas na escrita do código fonte, teste, compilação e empacotamento para distribuição. É preciso pensar na estrutura do projeto como algo que pode evoluir, ou talvez ter diferentes versões, fazendo com que tarefas como o build sejam extremamente importantes e bem arquitetadas.

O Maven

Em projetos Java, é comum a utilização de algum tipo de ferramenta de gerenciamento que permita a condução do processo de desenvolvimento. Muitos desenvolvedores utilizam a própria IDE para este fim, o que não deprecia de forma alguma o produto final construído, uma vez que não é a ferramenta que garante a qualidade do produto final, mas ajuda consideravelmente na produtividade.

O Maven é uma destas ferramentas, que foram desenvolvidas para auxiliar no processo de desenvolvimento de software na plataforma Java. Ela foi criada para melhorar o processo de construção do projeto Jakarta TURBINE, um framework Java para desenvolvimento de aplicações web. O projeto TURBINE utilizava outra ferramenta de apoio, o ANT, porém o processo de gerenciamento ficava muito complexo e sem um esquema padronizado, uma vez que o ANT baseia-se em tarefas e alvos, contidos em um arquivo descritor de tarefas de build, o BUILD.XML. Deste modo os membros do projeto TURBINE criaram o Maven para suprimir as limitações e definir uma padronização no desenvolvimento do projeto.

Atualmente o Maven encontra-se na versão 3.0.4 (versão disponível no momento em que este artigo é escrito) e desde o início de seu desenvolvimento os modelos de gerenciamento de projeto foram evoluindo, até que se oficializou como padrão o POM (Project Object Model – Modelo de Objeto de Projeto), que será visto em detalhes neste artigo.

Estrutura e organização de um projeto Maven

No Maven existe uma padronização da estrutura do projeto conhecida como Modelo de Objeto de Projeto, ou simplesmente POM. Este modelo define por meio de um arquivo XML todas as partes pertencentes ao projeto, como, dependências, número de versão, tipo de artefato gerado (JAR, WAR ou EAR), etc. Esta forma de definir a estrutura do projeto é chamada de Convenção sobre Configuração, ou seja, uma maneira pré-determinada de configuração da estrutura do projeto.

O POM é o principal ponto de partida de um projeto que será gerenciado pelo Maven, pois é o arquivo (pom.xml) que descreve e disponibiliza as informações e configurações do projeto. A Listagem 1 mostra a estrutura mínima deste arquivo.

 
<project xmlns="http://maven.apache.org/POM/4.0.0" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0      
	http://maven.apache.org/xsd/maven-4.0.0.xsd">


<modelVersion>4.0.0</modelVersion>
<groupId>br.com.yweti.devmedia</groupId>
<artifactId>artigo</artifactId>
<version>1.0.0-SNAPSHOT</version>
</project> 

Este arquivo fica no diretório raiz do projeto, e serve para informar ao Maven suas características. Como pode ser visto na ...