Neste artigo, daremos continuidade ao nosso estudo sobre o Maven. Como dissemos na primeira parte, ele, em si, é uma ferramenta de gerenciamento e automação de construção (build) de projetos. No entanto, com a disponibilidade de inúmeros plugins para os mais variados fins, o Maven transcende sua proposta original, tornando-se uma potente fonte de funcionalidades auxiliares para o projeto.

Na Easy Java de número 20, mostramos ainda a estratégia da ferramenta para facilitar o controle das bibliotecas utilizadas pelo projeto, ao assumir a responsabilidade por obtê-las e as instalar automaticamente. Isso, claro, presumindo que o Maven esteja bem configurado e que as bibliotecas sejam públicas ou estejam disponíveis no ambiente em que a ferramenta está sendo empregada.

Por fim, vimos também como a ferramenta estimula o emprego de boas práticas na implementação de soluções, ao adotar o conceito de programação por convenção (do inglês convention over configuration), no qual o Maven assume automaticamente que o seu usuário irá empregar a mesma metodologia e padrão de organização que ele considera ideal, poupando-o do trabalho tedioso de sempre ter que descrever as mesmas informações em cada projeto, como quais diretórios contêm código a ser compilado, o destino dos artefatos compilados, etc. Ao empregar inerentemente as práticas sugeridas pela comunidade, a ferramenta acaba as divulgando e estimulando que os projetos também as utilizem, aumentando a padronização e diminuindo a curva de aprendizado para novos desenvolvedores. Obviamente, qualquer convenção destas pode ser sobrescrita pelo usuário, que então deverá informar como quer que a ferramenta se comporte para seu projeto, prática somente aconselhada para casos de exceção, como projetos legados.

Maven em ação!
No artigo anterior, apresentamos alguns princípios básicos do Maven, como o uso de arquétipos para a criação de projetos Java, o conceito de dependências (bibliotecas utilizadas pelo projeto), o arquivo pom.xml (o coração da ferramenta, responsável por sua configuração e controle de todas as suas funcionalidades) e explicamos seu ciclo de vida de construção. Ao mesmo tempo em que explanávamos os princípios, os aplicávamos na prática, o que culminou na criação de um pequeno projeto exemplo, cujo propósito era exibir as últimas dezenas sorteadas pela Mega-Sena. Este projeto pode ser baixado no site da Edição anterior.

Prosseguindo com o nosso estudo, vamos rodar o estágio install do ciclo de vida padrão, que é um dos comandos mais básicos do Maven, para que possamos analisar as etapas de construção do pacote de publicação. Como vimos no artigo prévio, o estágio install, ao executar, automaticamente invoca os estágios a

...

O processo de criação de um projeto Java EE em geral envolve a criação de um diretório principal com vários subdiretórios, a configuração de diversos arquivos XML, a obtenção (via cópia ou download) de bibliotecas para o projeto e, posteriormente, a execução dos testes unitários, a criação dos pacotes de publicação, a geração de documentação javadoc, entre outras etapas. Normalmente, até algum tempo atrás, cada projeto tinha sua própria estrutura, seu próprio jeito de gerar pacotes, de efetuar cada um destes passos. Projetos complexos, com vários módulos, ainda podem precisar que estes sejam compilados em determinada ordem, para que o pacote final seja criado.

Como se pode imaginar, facilmente isso poderia se tornar um pesadelo para os projetos em manutenção ou com um desenvolvimento mais extenso, em equipes que envolvam alguns desenvolvedores, porque as mudanças estruturais realizadas por um desenvolvedor têm que ser comunicadas a cada um dos demais colegas, para que o projeto continue a compilar no computador de cada um. Considere, por exemplo, que o desenvolvedor A precisou incluir uma biblioteca. Antes de colocar no controle de versão o código que a utiliza, ele precisaria avisar a cada um de seus colegas que adicionou algo novo no projeto, dizer de onde baixar o novo componente (ou passá-lo de computador em computador) e se assegurar que todos equalizaram seus ambientes de desenvolvimento, para que o código continue compilando nas máquinas de seus colegas. Tempos depois, o desenvolvedor B precisa efetuar uma manutenção no projeto e descobre que uma versão nova da biblioteca supracitada fornece uma funcionalidade nova, que facilitará o seu trabalho. Mais uma vez, o ciclo de aviso e cópia do novo componente começa, com perda de tempo da equipe e correndo o risco de algum computador ficar desatualizado e um desenvolvedor perder tempo tentando achar um erro acarretado pelo uso da biblioteca antiga.

Outra situação possível, em um projeto de vários módulos: um desenvolvedor modifica um dos módulos básicos do sistema e não avisa os demais colegas, ou estes não deram atenção ao e-mail de alerta. Como resultado o código ou para de compilar ou passa a ter comportamento instável, porque o módulo alterado não foi recompilado nos computadores do restante da equipe.

Agora, imagine os cenários acima em uma fábrica de software, em que o ritmo de trabalho é intenso e os prazos impõem pressão às equipes. Facilmente podemos prever que bibliotecas serão adicionadas sem que o restante do time seja avisado, acarretando impedimento de compilação do código mais recente do projeto. Pessoas modificariam módulos e se esqueceriam de avisar as demais para pegarem a versão mais recente de código e recompilar as alterações; mudanças no processo de geração de pacotes que não são comunicadas, e daí em diante.

Finalmente, se forem consideradas equipes distribuídas, com seus membros trabalhando em home office, a complexidade de propagar mudanças estruturais do projeto aumenta muito. Nesses casos, até mesmo iniciar o projeto podia trazer muitas dores de cabeça, até toda a equipe conseguir estabilizar o ambiente de desenvolvimento de cada participante.
Visando solucionar estes e outros problemas, algumas ferramentas foram desenvolvidas para ajudar na organização dos projetos e foram bem sucedidas em seu intento, sendo a mais famosa delas o Apache Ant. O trabalho manual diminuiu bastante, mas ainda havia ...