fica aqui o aviso, todos os exemplos e materiais técnicos relacionados aos posts do blog estão disponíveis no http://code.google.com/p/felipemsantos/.

Uma forma simples de fazer isso é utilizar o componente Lang do projeto Apache Commons, esse camarada possui algumas classes que fazem o trabalho árduo pra você.

Veja a dificuldade de fazer isso:

public abstract class Entidade implements Serializable {

	/**
	 * Retorna o valor de id.
	 *
	 * @return o valor de id.
	 */
	public abstract Id getId();

	/**
	 * @see java.lang.Object#hashCode()
	 */
	public int hashCode() {
		// Para quem utiliza Hibernate este forma de uso do HashCodeBuilder
		// não é recomendada devido a problemas de "lazy initialization" de coleções.
		// return HashCodeBuilder.reflectionHashCode(this);
		return new HashCodeBuilder(17, 31).append(getId())
		        .append(super.hashCode()).toHashCode();
	}

	/**
	 * @see java.lang.Object#equals(java.lang.Object)
	 */
	public boolean equals(Object other) {
		return EqualsBuilder.reflectionEquals(this, other);
	}

	/**
	 * @see java.lang.Object#toString()
	 */
	public String toString() {
		return ToStringBuilder.reflectionToString(this,
		        ToStringStyle.MULTI_LINE_STYLE);
	}
}

Simples assim!

Pensou?! Sério, pensou?! Que tal mais alguns minutos?

Ok, agora pense no que você poderia estar fazendo se essa ferramenta realmente existir? Sei lá, tomar um café, conversar com os amigos de trabalho pra descontrair um pouco, fazer algo realmente útil e produtivo!

Apache Maven2, esse é o cara! A Apache Software Fundation (ASF) a alguns anos criou o ANT, uma ferramenta de build que consegue através de um arquivo de regras como “>realizar inúmeras tarefas e a utilizou para padronizar (ou pelo menos tentar padronizar) os diversos frameworks e projetos que ela (a ASF) mantém, porém as coisas nem sempre saiam como o esperado, como o ANT tem uma caracterísitica que fexibiliza e garante uma vasta possibilidade de configurações sobre como realizar uma determinada tarefa acabou que essa padronização não aconteceu como esperado. Ai então surgiu a idéia de criar algo que garantisse um padrão (independente do tipo de projeto) para tarefas referentes a construção de uma “distribuição” de um projeto, algo que fosse extensível, “plugável”, que possibilitassem o gerenciamento de questões como dependências e documentação técnica de um projeto, foi assim que o Maven foi criado.

Assim como o ANT o Maven se baseia em um arquivo (pom.xml) para realizar seu trabalho, porém, diferente dos famosos build.xml do ANT, onde a configuração dos “targets” é extremamente verborrágica, a configuração é feita de modo declarativa e muito mais simples.

Antes de continuar a ler este post:

• realize o download do Maven no site http://maven.apache.org/download.html
• A instalação é simples, basta descompactar o arquivo que você baixou (ZIP, TAR.GZ ou TAR.BZ2) em um diretório qualquer (por exemplo, /opt/apache-maven-2.2.1 ou c:\apache-maven-2.2.1)
• Ajuste o PATH do seu SO:
• no Linux (no meu caso Ubuntu), adicione no final do arquivo /etc/profile as linhas

export M2_HOME=/opt/apache-maven-2.2.1
export PATH=$M2_HOME/bin:$PATH

• no Windows basta criar a variável de ambiente M2_HOME apontando para o diretório c:\apache-maven-2.2.1 e alterar o PATH para %M2_HOME%\bin;%PATH%.

Para verificar se a intalação está correta digite mvn -v em um prompt de comando ou terminal e você deve ver o seguinte resultado:

felipe@ubuntu:~$ mvn -v (ou mvn –version)
Apache Maven 2.2.1 (r801777; 2009-08-06 16:16:01-0300)
Java version: 1.6.0_16
Java home: /opt/jdk/jdk1.6.0_16/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: “linux” version: “2.6.28-15-generic” arch: “i386″ Family: “unix”

Para começarmos a entender como o Maven trabalha e como podemos nos beneficiar da forma como ele trabalha vamos analisar os seguintes pontos que considero como básicos:

• Project Object Model (POM)
• Diretórios de um projeto Maven
• Dependências e Repositórios
• Ciclo de vida de um “build”
• Exstensibilidade (Plugins)

Considerando que você já fez o download e instalou o Maven na sua máquina, vamos começar.

Project Object Model (POM)

Em termos simples o POM é a forma como o Maven compreende o que é o seu projeto. Essa estrutura define algumas informações utilizadas pelo Maven durante a o processo de “build”, por exemplo para um projeto simples (uma biblioteca de componentes, por exemplo) O Maven tem que saber qual o nome deve ser utilizado pra gerar o “JAR” do projeto, essa informação é definida pela propriedade “artifactId”. O arquivo onde ficam descritas estas informações é o pom.xml que fica sempre na pasta raiz do seu porjeto. Veja o exemplo abaixo:

Arquivo pom.xml

OK, muita informação de uma vez. Vamos por partes:

• <modelVersion>4.0.0</modelVersion> é a versão do modelo POM em que o seu projeto será descrito para o Maven.
• <groupId>fms.exemplo</groupId> informa ao Maven que o seu projeto pertence ao grupo fms.exemplo. Essa informação em conjunto com o artifactId e a version é utilizada para organizar o seu projeto no repositório de dependências (falaremos sobre isso mais afrente).
• <artifactId>fms-maven-exemplo</artifactId> é o nome do seu projeto para o Maven.
• <packaging>jar</packaging> é a forma o seu projeto deve ser empacotado.
• <version>0.0.1-SNAPSHOT</version> é a versão do seu projeto.
• <name>Exemplo de Projeto Maven</name> é nome de exibição do projeto.
• <url>http://localhost/fms/fms-maven-exemplo/</url> é o link do site do projeto.
• <dependency>é uma declaração de dependência do seu projeto.
  • <groupId>junit</groupId> tem a memsa função que o groupId declarado anteriormente.
  • <artifactId>junit</artifactId> tem a memsa função que o artifactId declarado anteriormente.
  • <version>3.8.1</version>tem a memsa função que o version declarado anteriormente.
  • <scope>test</scope> é o escopo em que essa dependência deve ser utilizada pelo seu projeto.

Existem outras propriedades que podem ser (e com certeza são) muito úteis, porém vamos nos ater apenas as questões básicas nesse post.

Diretórios de um porjeto Maven

Se você já realizou o download e descompactou o exemplo citado no início do post, abra a pasta do projeto e você verá algo do tipo:

Estrutura de diretórios

Como você já deve ter percebido a estrtura de diretórios é bastante intuitiva. Porém não custa nada explicar:

• src – é do diretório padrão de código-fontes.
• main – é o diretório principal do seu projeto.
• java – é o diretório onde ficam os fontes java da sua aplicação.
• resources – é o diretório onde ficam os arquivos propriedades, XML, etc. da sua aplicação.
• test – é o diretório de testes do seu projeto.
• java – é o diretório onde ficam os fontes de teste da sua aplicação.
• resources – é o diretório onde ficam os arquivos de propriedades, XML, etc. utilizados pelos testes de sua aplicação.
• target – é o diretório onde ficam os arquivos resultantes de qualquer tarefa executada durante o build do seu projeto.

O Maven trabalha com essa estrutura de diretórios para facilitar a sua vida. Veja que arquivos de código-fonte e de configuração de testes ficam separados do código de sua aplicação, dessa forma o Maven sabe gerenciar o que é um teste e qual devem ser as dependências utilizadas durante um teste ou compilação do projeto.

Existem outros diretórios que podem ser utilizados, mas como falei antes, estamos apenas tentando entender o básico. Também é possivel alterar essa estrutura de diretórios para uma disposição de sua preferência, porém, para isso, é necessário declarar no pom.xml que diretórios são estes e para que devem ser utilizados, outro problema é que o Maven (e vários plugins desenvolvidos para ele) já veêm esses diretórios por padrão, logo, não é muito recomendado alterar esta estrutura.

Dependências e Repositórios

O Maven trabalha com um mecanismo de gerenciamento de dependências bem interessante. Vamos entender isso através de um exemplo:

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>

As linhas acima indicam que um projeto depende do framework jUnit versão 3.8.1 para compilar e executar os seu testes. Bem simples, não?! O Maven entende que durante a fase de compilação e execução dos testes ele precisa montar o “classpath” com este JAR. Opa, vamos com calma, de onde que vem esse JAR? Mágica?! O Maven trabalha com o conceito de “Repositórios de Dependências”. É o mecanismo pelo qual é possível identificar uma dependência e utilizá-la. No caso do jUnit, o Maven irá verificar se você já possui esse JAR em um repositório local (na sua máquina), caso contrário ele ira acessar o repositório central (http://repo1.maven.org/maven2) e irá buscar o grupo (groupId) junit e dentro dele o artefato (artifactId) junit e para este artefato a versão (version) 3.8.1.

jUnit no Repositório Central do Maven2

Observe que a disposição da dependência no repositório está totalmente relacionada ao groupId, artifactId e version de um projeto. Logo, o seu projeto também pode se tornar uma dependência de outros projetos. O mecanismo de dependências trabalha da seguinte forma, quando uma tarefa de build é iniciada, o Maven verifica se as dependências necessárias para a realização do build estão presentes no seu repositório local, que, por padrão fica em $HOME/.m2/repository (esse local pode ser alterado via configuração), caso você não possua a dependência, o Maven irá verificar a dependência no repositório central, encontrada a dependência a mesma será baixada para o repositório local e a tarefa será executada. Isso acontece para cada dependência do seu projeto.

As dependências de um projeto Maven possuem um escopo, e esse escopo auxiliam o Maven a compreender o que faz e o que não faz parte do “classpath” de um projeto. Por exemplo, se você estiver trabalhando em um seu “>sistema Web é possivel que você necessite das dependências da API de Servlets e JSP, porém você não deve distribuir seu sistema com esses JARs, logo, o Maven deve entender isso para não fazer besteira ao tentar empacotar o seu projeto. Os possíveis escopos de uma depêndencia são:

• compile (default) – caso nenhum escopo seja especificado este será utilizado. São dependências utilizadas em todos os “classpaths” de um projeto.
• provided – significa que o ambiente de execução do seu projeto (um Web Container, por exemplo) provê essa dependência. Este escopo também é utilizado para o classpath compilação e testes.
• runtime – como o proprio nome diz, indica que a dependência é necessária apenas em tempo de execução.
• test – indica que a dependência é utilizada apenas para compilar e executar testes.
• system – semelhante ao escopo “provided”, porém nesse caso você deve prover esta dependência, pois o Maven não ira buscá-la em um repositório.
• import – apenas disponível a partir do Maven 2.0.9, é utilizada apenas para dependências do tipo POM e para trabalhar com substituição de dependências e dependências transitivas.

Leia mais sobre o Mecanismo de Dependências do Maven em http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.

Ciclo de vida de um “build”
Chegando neste ponto você deve estar se pensando, “tudo bem, o Maven até agora não faz nada que eu não possa fazer sem ele! O que que ele faz que possa realmente me ajudar?” O Maven trabalha com o conceito de Ciclo de Vida de Build, ou seja, existem passos que são executados em sequência e que respeitam cada fase de um ciclo de vida para a construção, empacotamento e distribuição de qualquer tipo de projeto (Web, EJB, Mobile, etc.). Basta compreender um pequeno conjunto de comandos para que o Maven realize um conjunto de tarefas encadeadas para gerar o que for necessário.

Vejamos um exemplo, digamos que seja necessário gerar um site com informações sobre o seu projeto após o “build”, para isso basta incluir a tarefa “site” ao comando de build e pronto. Para verificar isso, no diretório raiz do seu projeto, digite o comando “mvn clean install site”, após o termino da operação você verá a mensagem:

[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————

Agora entre no diretório “target/site” do projeto e abra o arquivo index.html no seu navegador. O resultado é algo do tipo:

Site do projeto Maven

Este site é gerado com base nas informações descritas no pom.xml, assim, é possível gerar relatórios (como PMD, Checkstyle, FindBugs, JavaDoc, etc) e ter informações (caso você utilize um Servidor de Integração Contínua) continuamente renovadas sobre seu projeto, inclusive resultado de testes unitários equipe do projeto, localização do seu servidor de controle de versões, etc.

Mas voltando ao assunto, o Ciclo de Vida padrão do Maven se resume às seguintes fases:

• validate – valida se o projeto está correto e se toda a informação necessária para o build esta acessível.
• compile – compila o código-fonte do projeto.
• test – testa o código compilado usando frameworks de teste unitário (configurados nas dependências do projeto).
• package – emapcota o código-fonte compilado no formato em que ele deve ser ditribuido (JAR, WAR, EJB, etc.). O Maven entende a forma em que o seu projeto dever ser empacotado com base na tag do pom.xml.
• integration-test – processa e implanta o pacote, se necessário, em um ambiente de execução onde os testes podem ser executados.
• verify – executa qualquer verificação para avaliar que o pacote é valido e realiza testes baseados em critários de qualidade.
• install – instala o pacote no seu repositório local, assim é possível utilizar o seu projeto como dependêcnia de outro projeto localmente.
• deploy – feitos os testes e verificações, e gerado uma versão (release) do projeto, copia o pacote para um repositório remoto para compartilhamento do projeto com outros desenvolvedores.

Esta última fase é bastante útil quando existe um repositório de dependências da empresa em um local acessivel em uma rede local. Outra informação útil neste ponto é que quando o comando “mvn clean install site” foi executao o que fizemos foi informar ao Maven que o build deveria ser realizado partindo da fase de limpeza (clean) até a instalação no repositório local (install), assim todas as fases entre “clean” e “install” também são executadas.

Esta é uma visão bem “macro” do Ciclo de Vida de Build que o Maven utiliza, pois, dentro de cada fase existem algumas tarefas que são executadas, caso ocorra um erro ou uma tarefa falhe, dependendo da falha o “build é quebrado”, pois as fazes são encadeadas e respeitam o resultado da fase anterior.

Para mas informações leia sobre Ciclo de Vida de Builds Maven em http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.

Agora que entendemos um pouco como funciona um build com o Maven, a conclusão que podemos chegar é que para qualquer que seja o tipo de empacotamento do seu projeto (ou qualquer que seja o tipo de projeto) esse ciclo de vida sempre é respeitado, ou seja, sempre teremos que limpar a estrutura de diretórios, compilar os fontes, testar, empacotar, etc. Assim o Maven trata de forma uniforme e consistente qualquer projeto.

Exstensibilidade (Plugins)

O Maven foi feito para ser extensível, pois a idéia é que em cada fase você possa fazer mais do que o básico. Outro conceito que o Maven apresenta é que para cada fase (phase) existem várias metas (goals) a serem atingidas, assim é possivel trabalhar com plugins extendendo as fases do “build” para atingir resultados mais interessantes. Um exemplo de uso dos plugins é que você pode informar ao Maven como ele deve trabalhar de forma mas específica, por exemplo, digamos que na sua empresa todos os fontes devem ser escritos para a VM 1.5, independente do JDK utilizado pelo Maven, isso pode ser configurado da seguinte forma:

Configuração do maven-compiler-plugin

Ou seja, acabamos de dizer ao Maven que o plugin “maven-compiler-plugin” deve informar ao compilador que o código-fonte deve ser compilado para a VM 1.5.

Outro aspecto interessante é que os plugins não se limitam apenas em ampliar o trabalho realizado em uma fase do build, mas também, de realizar tarefas que não são padrões do build. Por exemplo, podemos adicionar o plugin do PMD para realizar testes de métricas de qualidade no código-fonte e gerar relatórios no site do projeto. Para executar o PMD e seus relatórios sobre o nosso código-fonte basta adicionar as seguintes linhas no pom.xml do seu projeto:

Configuração do maven-pmd-plugin

Após incuir essa configuração execute “mvn clean install site” novamente e verifique o site do projeto no navegador.

Site do projeto com o Relatório do PMD

Você verá que uma nova área foi criada (Project Reports) e nela existe um link para os relatórios gerados pelo PMD. Para uma lista de plugins acesse http://maven.apache.org/plugins.

Uma outra informação que pode estimular a sua curiosidade é que o Maven é acapaz de gerar sites extremamente complexos e ricos de informações, acesse o site do Maven (http://maven.apache.org). Ele é totalmente gerado com Maven. Agora você deve perceber que outros sites de inúmeros frameworks e componentes Java possuem uma estrutura semelhante e é exatamente o que você está pensando! Todos são gerados pelo Maven!

Podemos concluir que o Maven é uma ferramenta que auxilia muito o passo-a-passo chato e massante da geração ou construção de releases de um projeto. Combinando os plugins corretos e uma ferramenta de Integração Contínua (Hudson, por exemplo) você pode ter informações relevantes sobre seus projetos de forma consistente, padronizada e inteligente.

Uma sugestão para quem quer começar a utilizar esse camarada e usa Eclipse é instalar o plugin M2Eclipse que faz integração com Maven. Ele ajuda na configuração do pom.xml, chamadas ao Maven para realizar builds, inclusão de dependências e para quem não está acostumado ainda com as possíveis opções de configuração do pom.xml ele possue um assitente visual bem interessante, outro ponto forte é que ele faz integração com o plugin Subclipse instala no “help” do Eclipse o livro “Maven: The Definitive Guide”, para quem está começando é um ótimo material.

Outro aspecto muito interessante é que, como o Maven implementa um padrão de trabalho, para equipes que desejam implantar um processo ou metodologia ágil e integrada ele se encaixa perfeitamente. Basta um esforço inical, para definição de um padrão de relatórios e tarefas que fazem parte sempre do build dos sistemas produzidos pela sua equipe e pronto.

Para mais informações acesse o site do Maven.

Deixe um comentário ou dúvidas, critique, colabore!
Até mais.