Exemplo de Utilização

Agora que se conhece o básico da configuração e como o Maven gerencia as dependências e os repositórios, podemos passar para uma demonstração de como realmente funciona uma build usando Maven.

Abra o console (o aplicativo de linha de comando) e vá até a pasta do projeto que contem o arquivo “pom.xml”. Nesta pasta, digite (você tem que estar conectado na internet para executar este comando):

mvn compiler:compile

onde:

“mvn” é o nome do executável que chama o Maven no seu ambiente. Sempre que for executar qualquer comando no Maven, deve-se chamar esse executável. Se é a primeira vez que executa o compilador do Maven, ele deve baixar algumas dependências do seu repositório na internet e após baixar todas as dependências, ele vai executar o comando “compile” do plugin “compiler”.

Todas as funcionalidades do Maven são fornecidas por plugins, que são conjuntos de código que fazem um trabalho específico ou vários trabalhos relacionados a uma característica específica de um projeto. O plugin que foi executado no exemplo anterior é o plugin compilador do Maven, que compila todos os arquivos de código fonte disponibilizados em “src/main/java” e os envia pra pasta “target/classes” dentro da pasta do projeto. O Maven cria automaticamente uma pasta chamada “target” no diretório do projeto para colocar todos os artefatos que foram gerados.

Os plugins que são utilizados em um projeto também precisam ser declarados no POM. Logo abaixo mostramos como declarar um plugin no Maven:

  <?xml version="1.0" encoding="UTF-8"?>
  <project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.maujr</groupId>
  <artifactId>aprendendo-maven2</artifactId>
  <packaging>war</packaging>
  <version>1.0.0</version>
  <inceptionYear>2006</inceptionYear>
  <name>Aprendendo o Maven 2</name>
 <description>
         Aprendendo a utilizar o Maven 2 em projetos Java
 </description>
 <dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>3.8.1</version>
 <scope>test</scope>
 </dependency>
 </dependencies>
 <build>
 <plugins>
 <plugin>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
 <source>1.5</source>
 <target>1.5</target>
 </configuration>
 </plugin>
 </plugins>
 </build>
 </project>

Como se pode observar no exemplo acima, o nó <build/> contém informações gerais sobre o processo de build do projeto, é nele que nós poderíamos definir uma estrutura de diretórios diferente do padrão do Maven. E é neste nó que se deve declarar o nó <plugins/> que contem os plugins utilizados no projeto.

Para definir um plugin, é necessário criar um nó <plugin/> dentro do nó <plugins/> e nele definir as informações específicas do plugin, usando os nós: <groupId/>, <artifactId/>, <version/> e <configuration/>. O funcionamento destes nós é idêntico aqueles já vistos anteriormente, apenas <configuration/> ainda não foi visto, porque ele é específico da declaração do plugin. É neste nó que são definidas as propriedades e configurações específicas para a execução do plugin.

No nosso exemplo, nós redefinimos duas variáveis de configuração do plugin, <source/> e <target/>, para indicar o desejo de que o compilador gere classes que são compatíveis apenas do Java 1.5 em diante. Para saber todas as variáveis do plugin “compiler”, basta ir ao seu site: http://maven.apache.org/plugins/maven-compiler-plugin
Existem plugins para a automatização de várias tarefas dentro do Maven, a lista oficial encontra-se no próprio site da ferramenta: http://maven.apache.org/plugins/index.html

Além deste site, existem várias outras comunidades que desenvolvem plugins para o Maven, basta procurar na internet.

Desenvolvendo um projeto web com o Maven 2

Normalmente, para desenvolver um projeto web em Java, se faz necessáro instalar um servidor web, configurá-lo junto ao seu ambiente de desenvolvimento e começar a trabalhar com ele. A integração entre as ferramentas não costuma ser simples e a maioria dos servidores web disponíveis são pesados e difíceis de serem configurados. Tendo em vista estes problemas, foi desenvolvido um plugin para o Maven, onde com um mínimo de configuração, pode-se ter acesso ao servidor web Java Jetty rodando para fazer todos os testes da sua aplicação.

Para utilizar o plugin do Jetty no seu projeto, basta apenas adicioná-lo ao seu projeto, da mesma forma que o plugin compilador foi adicionado anteriormente, vejamos como o POM deve ficar:

 <?xml version="1.0" encoding="UTF-8"?>
  <project>
      … mesmo conteúdo do anterior
  <build>
  <plugins>
              … mesmo conteúdo do anterior, só muda daqui pra frente
  <plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>maven-jetty6-plugin</artifactId>
 <version>6.0.0beta17</version>
 <configuration>
 <contextPath>/</contextPath>
 <connectors>
 <connector
             implementation="org.mortbay.jetty.nio.SelectChannelConnector">
 <port>80</port>
 <maxIdleTime>60000</maxIdleTime>
 </connector>
 </connectors>
 </configuration>
 </plugin>
 </plugins>
 </build>
 </project>

Como se pode visualizar, a declaração do plugin é idêntica a anterior, mudando apenas as configurações específicas do plugin, vejamos o que cada nó significa:

  • <contextPath/> – contexto web pelo qual a aplicação vai ser acessada, declarando o valor como “/” significa que a aplicação fica na raiz do servidor;
  • <connectors/> – são os responsáveis por gerenciar as conexões do navegador, cada <connector/> pode ser de um tipo e “escutar” por requisições em uma porta diferente, a implementação mais comum é o SelectChannelConnector, pois ele é o mais rápido de todos;
  • <port/> – é a porta na qual o servidor deve esperar por conexões, a porta “80” é a porta padrão do http;

Com essa configuração, já podemos executar a aplicação web no servidor. Inicialmente, deve-se executar o comando para chamar o servidor (se é a primeira vez que você o faz, deve estar conectado a internet):

mvn jetty6:run

Utilizando esse comando, instruímos o Maven a inicializar o servidor web dentro do nosso projeto. Quando aparecer na linha de comando a mensagem “Started Jetty Server”, o servidor já pode começar a receber requisições. Com base nas configurações realizadas, a aplicação-exemplo estará disponível no endereço http://localhost/.
Sempre que existir atualização das classes ou dos arquivos de configuração da aplicação, o servidor precisa ser reiniciado. Contudo, existe a possibilidade do servidor descobrir automaticamente que houve mudanças, para tanto, adicione o nó <scanIntervalSeconds/> a configuração do plugin com o valor em segundos que é a freqüência com a qual ele vai procurar atualizações na aplicação e se reiniciar sozinho.

Desenvolvendo um projeto Java J2EE com o Maven 2

Para um projeto Java J2EE que possui vários sub-projetos, tais como ejb, web, web service e cliente, deve-se configurar o projeto através de módulos. Onde cada módulo seria responsável por um destes sub-projetos, como o pom.xml exemplo abaixo:

 [...]
  <modules>
  <module>ejb</module>
  <module>web</module>
  <module>streamer</module>
  <module>wsappclient</module>
  <module>ear</module>
  </modules>[...]

Na figura de uma aplicação exemplo acima, o arquivo daytrader/pom.xml contem os elementos POM que são compartilhados entre todos os módulos. Este arquivo contem a lista de modulos que o Maven deverá construir.

E para cada modulo, haverá um arquivo pom.xml mais específico que irá referenciar o arquivo do diretório pai, conforme exemplo abaixo que mostra módulo ejb que irá executar utilizando o servidor de aplicação Geronimo da Apache.

 <project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
  <groupId>org.apache.geronimo.samples.daytrader</groupId>
  <artifactId>daytrader</artifactId>
  <version>1.0</version>
  </parent>
  <artifactId>daytrader-ejb</artifactId>
  <name>Apache Geronimo DayTrader EJB Module</name>
 <packaging>ejb</packaging>
 <description>DayTrader EJBs</description>
 <dependencies>
 <dependency>
 <groupId>org.apache.geronimo.samples.daytrader</groupId>
 <artifactId>daytrader-wsappclient</artifactId>
 <version>1.0</version>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>org.apache.geronimo.specs</groupId>
 <artifactId>geronimo-j2ee_1.4_spec</artifactId>
 <version>1.0</version>
 <scope>provided</scope>
 </dependency>
 <dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.0.3</version>
 <scope>provided</scope>
 </dependency>
 </dependencies>
 <build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-ejb-plugin</artifactId>
 <configuration>
 <generateClient>true</generateClient>
 <clientExcludes>
 <clientExclude>**/ejb/*Bean.class</clientExclude>
 </clientExcludes>
 </configuration>
 </plugin>
 </plugins>
 </build>
 </project>

Implantando o sistema (deployment)

Anteriormente, discutiu-se como executar nossa aplicação web no servidor do próprio Maven, no entanto, no momento da implantação, deve-se faze-lo em um servidor de produção, tanto em formato WAR quanto na estrutura de diretórios padrão de aplicações web em Java.

Para gerar um WAR da aplicação, é preciso digitar o seguinte comando no console na pasta raiz do projeto (a que contém o pom.xml):

mvn package

A pasta “target” do projeto é aquela que receberá os produtos da build, dentro dela haverá uma pasta com o nome “aprendendo-maven2-1.0.0”, que contém a estrutura completa da aplicação web, com os arquivos compilados, as dependências em bibliotecas na pasta “WEB-INF/lib” (o Maven copia automaticamente qualquer dependência de escopo “runtime”, “compile” ou “system”). Além desta pasta, é possível encontrar o arquivo “aprendendo-maven2-1.0.0.war”, que é o arquivo WAR gerado por este projeto, nele também são encontrados todos os arquivos que estavam dentro da pasta “webapp” do projeto do Maven, as classes e arquivos de configuração e todas as bibliotecas. O arquivo gerado está pronto para ser implantado em qualquer servidor web Java que suporte a especificação de servlets.

Uma vez que o nó <packaging/> do projeto foi definido com o valor “war”, o Maven sabe que na fase “package” do ciclo de vida do projeto ele deverá ser empacotado como um arquivo “war”. O ciclo de um projeto no Maven é definido normalmente através das seguintes fases (para uma lista completa verifique no site: http://maven.apache.org/articles.html ):

  • validate – valida se o projeto está corretamente configurado e se o ambiente está com as devidas variáveis de ambiente configuradas;
  • compile – compila o código fonte do projeto;
  • test – executa os testes unitários do projeto;
  • package – empacota o projeto conforme definido na sua descrição;
  • integration-test – executa os testes de integração;
  • verify – verifica a qualidade da aplicação e do código (normalmente com relatórios de análize de código, resultados de testes de integração e carga);
  • install – instala o artefato gerado no repositório local do Maven;
  • deploy – envia o artefato gerado para um servidor remoto para que ele seja implantado;

Quando se instrui o Maven a executar qualquer uma destas fases, ele automaticamente executa todas as fases anteriores, no nosso caso, como se requisitou que o Maven executasse a fase “package”, ele automaticamente executou as fases “validate”, “compile” e “test” antes de executar “package”. Alguns plugins se associam automaticamente a fases de um projeto, para que eles sejam executados sem que o usuário precise indicar o seu uso. Um caso comum é do plugin “compiler”, que é registrado para executar sempre na fase “compile” de um projeto.

Verificando a lista de plugins do Maven, encontra-se um plugin chamado de “war”, que é aquele responsável pelo empacotamento das classes na estrutura de uma aplicação web.

É possível também indicar quais plugins serão executados, através do comando:

mvn resources:resources compiler:compile war:war

Neste comando, solicita-se ao Maven que ele execute, sequencialmente, três plugins. Primeiro, ele executa o plugin “resources” com a ação “resources”, que copia todos os arquivos que estão em “src/main/resources” para a pasta “target/classes”, depois ele executa o plugin “compiler” com a ação “compile”, que provoca a compilação de todos os arquivos “.java” disponíveis em “src/main/java” e copie os arquivos resultantes para “target/classes”. Por último, executa-se o plugin “war” com a ação “war” que vai criar um arquivo “war” com o conteúdo da pasta “src/main/webapp”, adicionando as dependências na pasta “WEB-INF/lib” do arquivo e copiando os arquivos que estão em “target/classes” para a pasta “WEB-INF/classes”.

É claro que é muito mais simples e cômodo simplesmente digitar “mvn package” e deixar o Maven cuidar de todo o resto, contudo existem casos específicos que necessitam de um controle mais fino do que está acontecendo no build do projeto.

Gerando relatórios e informações sobre o projeto

Analisaremos agora uma característica do Maven que o diferencia de outras ferramentas mais simples, que é a capacidade de gerar informações a partir do código fonte e do POM.

As informações podem ser geradas de várias formas diferentes, elas podem, inclusive, ser conteúdo estático que você gostaria de incluir na documentação do projeto (como um guia para o usuário), mas em sua maior parte a documentação gerada pelo Maven está intimamente relacionada a obtenção de informações sobre a qualidade do projeto, com análises estáticas de código, conformidade com padrões de codificação, resultados dos testes de unidade e outros.

Para lidar com isso, o Maven tem um conjunto de plugins relacionados a geração de relatórios que podem ser tão simples como a geração de um “javadoc” e páginas HTML referenciáveis contendo código-fonte, como também análises complexas de busca de padrões de bugs comuns em código ou cobertura dos testes unitários.

Vejamos o exemplo de um POM com relatórios configurados:

 <?xml version="1.0" encoding="UTF-8"?>
  <project>
                  .....informações gerais do projeto
  <build>
                  .....configuração dos plugins do build
  </build>
  <reporting>
  <plugins>
  <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jxr-plugin</artifactId>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-javadoc-plugin</artifactId>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-checkstyle-plugin</artifactId>
 </plugin>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-pmd-plugin</artifactId>
 </plugin>
 </plugins>
 </reporting>
 </project>

Os relatórios são definidos nos nós <reporting/>. Cada relatório funciona como um plugin e podem ser configurados da mesma forma que os outros plugins vistos anteriormente, a única diferença é que eles são executados quando é gerada a documentação do projeto, a através do plugin “site”. Para gerar a documentação do projeto, você só precisa digitar o seguinte comando:

mvn site

O Maven vai automaticamente gerar toda a documentação possível sobre o projeto (com base no POM) e executar todos os plugins de relatórios definidos. O site do projeto vai estar disponível dentro da pasta “target/site” do seu projeto, basta abrir o arquivo “index.html” ver o resultado gerado pelo Maven.

No exemplo apresentado, o Maven executará os plugins “javadoc”, que gera como relatório o Javadoc de todos os arquivos fontes do sistema, o “jxr”, que gera como relatório todo o código fonte do sistema em formatado em HTML, o plugin “checkstyle” que gera uma análise do código quanto a tua aderência a um padrão de desenvolvimento específico (quando nenhum padrão é definido, toma-se como base as regras do Java) e o “pmd”, que analiza o código em busca de bugs e outros problemas comuns.

De posse destas informações, um gerente de projetos vai ter muito mais facilidade ao montar uma análise completa do estado atual e até mesmo reforçar algum critério ou padrão de desenvolvimento, com base nas ferramentas de relatório definidas. Além destes, existem vários outros plugins de relatório que geram informações sobre o projeto automaticamente também podem ser grande valia tanto para os gerentes quanto para os próprios desenvolvedores, pois eles estarão garantindo a qualidade do software.

Executanto testes unitários

A estrutura padrão de diretórios do Maven 2, temos um conjunto de pastas específicas para reunir informações sobre os testes unitários do projeto. Se são utilizados frameworks de testes unitários como JUnit ou TestNG para desenvolver os testes, pode-se configurar o Maven para que compile e execute automaticamente os testes do projeto.

Para executar os testes, basta digitar o seguinte comando:

mvn test:test

O Maven vai automaticamente executar os testes do projeto utilizando JUnit ou TestNG através da declaração da dependência no seu POM. Se você declarou o JUnit como dependência do projeto, ele vai tentar executar os testes utilizando o JUnit, se você declarou o TestNG como dependência, ele vai tentar executar os testes utilizando o TestNG.

  1. No comments yet.
Submitting Comment, Give me a second...

Leave a comment

 

Allowed tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
Trackbacks & Pingbacks ( 0 )
  1. No trackbacks yet.