Sempre que eu preciso estudar sobre algo relacionado a Java deparo-me com uma das seguintes possibilidades:

• O projeto não tem qualquer documentação, ou a documentação é mínima/insuficiente;
• A documentação é gigante e levaria anos de leitura para entender como algo simples funciona;
• A documentação está em um dialeto que sou incapaz de decifrar e que apenas a comunidade Java parece ser capaz de entender. Este caso me lembra a época de colégio e faculdade onde os professores utilizavam várias aulas para tratar da introdução óbvia e passavam rapidamente pela parte que mais merecia atenção.

Há cerca de um ano, tive meu primeiro contato com Java trabalhando em projetos reais. Na época, a equipe com que trabalhava utilizava projetos criados com o Netbeans e uma série de procedimentos para lidar com o gerenciamento de dependências entre os projetos. Nos últimos meses a equipe vem aplicando uma série de inovações, como a mudança do CVS para o Git, testando metodologias ágeis de gerenciamento de projeto, como SCRUM e XP, migrando os projetos para a estrutura do Maven, entre outras.

A motivação para a migração para o Maven era que o gerenciamento de dependências seria bastante simplificado, mas por muito tempo essa decisão foi adiada porque não havia uma documentação concisa e rápida sobre como funcionava o Maven na prática. Era necessário ler muito material sobre o Maven, o que demandava tempo. Assim que dispomos deste tempo, resolvemos migrar os projetos para o Maven, mais ou menos, na mesma época em que migramos o sistema de controle de versão para o Git. A seguir, relato como foi esse processo (da parte do Maven, apenas), na esperança que possa auxiliar outros na mesma situação. Adianto que o esforço se paga rapidamente!

Maven é uma ferramenta que realiza várias tarefas:

• Gerenciamento de dependências
• Compilação de fontes
• Execução de testes automatizados
• Empacotamento
• Distribuição
• Virtualmente qualquer coisa a partir de plugins

Nossa primeira decisão foi criar um proxy para o Maven, e para isso utilizamos o Nexus, cuja instalação é trivial, bastando seguir as instruções do projeto, que são exceção à documentação típica que citei no início do artigo. Este passo não é obrigatório e não será discutido neste artigo, mas possui várias vantagens ao se trabalhar em uma equipe de desenvolvedores.

Todo projeto Maven possui um arquivo pom.xml que relaciona as dependências do projeto bem como a estrutura como o projeto estará organizado. É possível herdar configurações de outro pom.xml, favorecendo a modularidade e não repetição de código (princípio DRY). Outro princípio utilizado é o Convenção Sobre Configuração. Isto significa que apenas alguns parâmetros de configuração são essenciais. Para os outros, quando não especificados, certas convenções serão assumidas.

Por exemplo, um projeto Maven típico terá a seguinte estrutura de arquivos:

projeto
 -pom.xml
 -src
  -main
   -java
    -br
      -com...
  -test
   -java
    -unit_test.java
 -resources
  -META-INF
  -logo.png

Ou seja, o projeto será composto pelo pom.xml, um diretório src, onde ficarão os fontes (dentro do sub-diretório java se os fontes estiverem em Java), um diretório test onde estarão os testes automatizados da aplicação e um diretório resources, onde ficarão os recursos do projeto. Podem ser imagens obtidas com getResource(“/logo.png”), por exemplo, ou folhas de estilo e javascripts que farão parte de uma aplicação web.

Estes projetos são referidos como artefatos, na terminologia do Maven. Após instalar o Maven, execute a linha abaixo para gerar um artefato vazio, de modo que possamos explorá-lo:

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false