Instalação e Configuração

Atualmente o Maven é distribuído em vários formatos: um arquivo de instalação tar/gzipped, zip, exe, entre outros. Iremos utilizar aqui a release candidate 1 do maven 1.0 (maven-1.0-rc1.zip). Siga os passos abaixo:

1. Faça o download do arquivo maven-1.0-rc1.zip (veja links);
2. Crie a variável de ambiente MAVEN_HOME apontando para o diretório aonde maven foi descompactado;
3. Adicione a pasta $MAVEN_HOME/bin no seu PATH

Obs: Tenha certeza que o Java está instalado corretamente e a variável JAVA_HOME setada.

Para ter certeza de que tudo foi instalado corretamente, vá até ao prompt de comando e digite maven -v. Se você vir o que segue abaixo, significa que a instalação foi um sucesso.

 __  __
|  \/  |__ Jakarta _ ___
| |\/| / _ \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|   v. 1.0-rc1-SNAPSHOT

Exemplo de utilização

 __  __
|  \/  |__ Jakarta _ ___
| |\/| / _ \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|   v. 1.0-rc1-SNAPSHOT


Enter a project template to use: [default]
Please specify an id for your application: [app]
Please specify a name for your application: [Example Application]     
[copy] Copying 1 file to <diretório do projeto>\src\java\com\neki     
[copy] Copying 3 files to <diretório do projeto>\src\test\com\neki     
[copy] Copying 1 file to <diretório do projeto>     
[copy] Copying 2 files to <diretório do projeto>

BUILD SUCCESSFUL
Total time: 5 seconds

 __  __
|  \/  |__ Jakarta _ ___
| |\/| / _ \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|   v. 1.0-rc1-SNAPSHOT

Attempting to download maven-SNAPSHOT.jar.
Overriding previous definition of reference to clover.classpath

java:prepare-filesystem:java:compile:    
	[echo] Compiling to <diretório do projeto>/target/classes
	
java:jar-resources:
Copying 1 file to <diretório do projeto>\target\classes

test:prepare-filesystem:    
	[mkdir] Created dir: <diretório do projeto>\target\test-classes    
	[mkdir] Created dir: <diretório do projeto>\target\test-reports

test:test-resources:

test:compile:    
	[javac] Compiling 3 source files to <diretório do projeto>\target\test-classes

test:test:    
	[junit] dir attribute ignored if running in the same VM    
	[junit] Running com.neki.AppTest    
	[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.05 sec

jar:jar:    
	[jar] Building jar: <diretório do projeto>\target\app-1.0.jar

BUILD SUCCESSFUL
Total time: 18 seconds

Processamento do POM

Processado como um script Jelly, o já familiar POM poderá dentre outras coisas, ser estendido e/ou conter trechos programados. Na verdade, na grande maioria das vezes, não precisaremos nos preocupar como funcionam scripts em Jelly, porém teremos o poder de trabalhar com estruturas condicionais, de repetição, sobrescrever propriedades etc.

Abaixo, segue um exemplo:

<?xml version="1.0" encoding="ISO-8859-1"?>
<project>  
	<pomVersion>3</pomVersion>  
	<id>maven</id>  
	<name>Maven</name>  
	<currentVersion>1.0-b5-dev</currentVersion>  
	<organization>    
		<name>Apache Software Foundation</name>    
		<url>http://jakarta.apache.org/</url>    
		<logo>/images/jakarta-logo-blue.gif</logo>  
	</organization>  
	<inceptionYear>2001</inceptionYear>  
	<package>org.apache.${pom.artifactId}</package>  
	<logo>/images/${pom.artifactId}.jpg</logo>  
	<description>    Maven is a project that was created in ${pom.inceptionYear}.  </description>  
	<shortDescription>    ${pom.name} is a Java Project Management Tool  </shortDescription>
</project>

As partes em negrito serão substituídas pelos valores descritos no POM.

Herdando um POM

Abaixo, segue um exemplo de herança:

<?xml version="1.0" encoding="ISO-8859-1"?>  
<project>    
	<extend>project.xml</extend>    
	<id>super-extendo</id>    
	<name>Super Extendo</name>    
	<build>      
		<unitTest>        
			<includes>          
				<include>**/*Test*.java</include>        
			</includes>        
			<excludes>          
				<exclude>**/TestAll.java</exclude>          
				<exclude>**/*Abstract*.java</exclude>        
			</excludes>      
		</unitTest>    
	</build>  
</project>

maven.xml

Esse é um arquivo 'especial' lido pelo Maven durante o processamento. Aqui, você poderá sobrescrever goals e/ou criar um procedimento especial para o seu projeto - copiar coisas, invocar outras goals, criar uma goal, entre outros.

Maven utiliza scripts escritos em uma linguagem denominada: Jelly ( http://jakarta.apache.org/commons/sandbox/jelly/), portanto, qualquer tag Jelly, válida, poderá ser colocada dentro de um arquivo maven.xml.

Exemplo

Nota: Abaixo, apresentaremos um exemplo ilustrativo, pois o Maven não define a goal 'compile' como default.

Um exemplo de maven.xml:

01 <project
02   default="nightly-build"
03   xmlns:j="jelly:core"
04   xmlns:u="jelly:util">
05
06   <goal name="nightly-build">
07     <!-- Any ant task, or jelly tags can go here thanks to jeez -->
08     <j:set var="goals" value="compile,test" />
09     <mkdir dir="${maven.build.dir}" />
10     <u:tokenize var="goals" delim=",">${goals}</u:tokenize>
11     <j:forEach items="${goals}" var="goal" indexVar="goalNumber">
12       Now attaining goal number ${goalNumber}, which is ${goal}
13       <attainGoal name="${goal}" />
14     </j:forEach>
15   </goal>
16 </project>

• Linha 01 - elemento principal de todos os arquivos maven.xml;
• Linha 02 - o atributo default (default="nightly-build") definirá a goal que será executada quando nenhum parâmetro for passado pelo maven, ou seja, simplesmente executando maven na linha de comando;
• Linha 03 - seguindo, temos as declarações de alguns XML namespaces, por exemplo: xmlns:j="jelly:core", que diz ao Jelly que todos os elementos XML prefixados com j: são parte de uma tag library predefinida, registrada com o identificador core dentro do Jelly;
• Linha 04 - xmlns:u="jelly:util", que diz ao Jelly que todos os elementos XML prefixados com u: são parte de uma tag library predefinida, registrada com o identificador util dentro do Jelly;
  
  Nota:
  1. Qualquer tag library Jelly que você queira utilizar dentro do maven.xml deverá estar declarada no elemento project e ter um namespace definido.
  2. O Maven já mantém pré-registrado a tag library jeez com um prefixo vazio. Essa tag agrupa as tag libraries Ant e werkz dentro de um namespace. Isso permite, que o Maven utilize qualquer tag Ant ou werkz sem precisar definir um namespace, fazendo com que o processo de migração de qualquer fragmento de script Ant, seja bastante simples.
  
  
  
• Linha 06 - Similar as targets do Ant, as goals do Maven irão agrupar uma série de atividades a serem executadas. Dentro delas, poderemos colocar qualquer tag Ant. Para executar uma goal definida no maven.xml, basta passar o nome da goal parâmetro para o Maven na linha de comando. Por exemplo, para executar a goal 'nightly-build', definida no nosso exemplo, basta digitar:
  
  

  > maven nightly-build
  

  Nota:
  1. Os plug-ins escritos para o Maven, sempre colocam como prefixo da goal o seu próprio nome, sendo fácil identificá-lo. Por exemplo: jar:jar, a goal jar definida pelo plug-in para criar um arquivo jar para o seu projeto
  
  
  
• Linha 08 - Dentro de cada goal, poderemos ter qualquer tag Jelly ou Ant, como apresentado em Nota acima. No nosso exemplo: <j:set var="goals" value="compile,test"/> , utilizando o namespace j:, definido elemento project, invocaremos a função set da tag library core do Jelly. Essa função irá setar a variável, cujo nome está definido no atributo var, com o valor colocado no atributo value.
• Linha 09 - <mkdir dir="${maven.build.dir}"/>, irá executar task mkdir do Ant, criando o diretório especificado pela variável ${maven.build.dir}.
• Linha 10 - <u:tokenize var="goals" delim=",">${goals}</u:tokenize>, utilizando o namespace u:, definido no elemento project, invocaremos a função tokenize da tag library util do Jelly. Atributos:
  
  
  1. O Atributo var será setado com o valor na nova lista;
  2. O atributo delim é o delimitador utilizado para separar os itens da string;
  3. No corpo da tag tokenize, encontramos a variável goals, setada algumas linhas acima, que contém compile e test separados por vírgula.
• Linha 11 a 14 - Aqui temos a função forEach: <j:forEach items="${goals}" var="goal" indexVar="goalNumber">, que irá facilitar a vida quando o assunto é estrutura de repetição. Atributos:
  
  
  1. O atributo items é uma expressão que irá conter a coleção a ser iterada;
  2. O atributo var especificará o nome da variável que receberá cada item da coleção durante o processamento
  3. O atributo indexVar conterá o nome da variável que irá receber o contador com o número de elementos a serem processados (zero-based).
  
  
  Dentro da função, temos o output de um texto que irá informar o nome da goal e o número a ser processado e invocará a goal, utilizando a tag werkz: attainGoal.

Customizando o Maven através do maven.xml

Até agora, vimos como compilar classes Java utilizando o Maven e também criar arquivos jars. Vimos também, que através do arquivo maven.xml, residente na mesma pasta do arquivo project.xml, podemos customizar as ações do Maven. Veremos agora, como definir, além de goals, pre e post goals.

01 <project default="foobar-dist" xmlns:m="jelly:maven">
02 
03   <preGoal name="java:compile">
04     <attainGoal name="xdoclet:webdoclet"/>
05   </preGoal>
06 
07   <goal name="foobar-dist">
08     <attainGoal name="war:install" />
09   </goal>
10
11   <postGoal name="war:war">
12     <mkdir dir="${test.result.dir}"/>
13     <echo>Creating directories</echo>
14   </postGoal>
15
16 </project>

Acima, colocamos um exemplo de maven.xml. Repare a goal default do projeto, aqui definida como: foobar-dist. A goal foobar-dist é simplesmente um wrapper para uma outra goal denominada war:install. A goal "install" do Maven WAR Plug-in, cria um war e publica-o dentro do repositório. A instrução "attainGoal" irá executar a goal descrita no atributo name.

O elemento preGoal instrui o Maven a executar as tarefas definidas dentro dele, antes de executar a goal especificada no nome do atributo. Isso pode gerar alguma confusão às vezes. Note que a preGoal (java:compile) é diferente da goal default (foobar-dist). A goal default para esse projeto, instala o arquivo war. Entretanto, o WAR Plug-in precisa compilar arquivos Java antes de criar o arquivo WAR. A preGoal especificada está muito mais ligada a goal java:compile, do que a goal foobar-dist. Nesse caso, a preGoal irá executar um Maven Xdoclet Plug-in.

Um postGoal pode ser especificado para qualquer goal implícita que seja parte da goal default ou a própria. No exemplo, a postGoal é especificada para a goal war:war, que é executada antes da goal war:install. A postGoal especifica que um dado diretório deve ser criado depois de construído o WAR.

Plug-in Properties

Os Plug-ins são carregados depois de processada a seqüência de propriedades definidas acima, porém, o PluginManager foi programado para não sobrescrever os valores que tiverem sido previamente setados. Isso funciona de forma oposta ao processamento normal das propriedades do Maven, uma vez que os Plug-ins só poderão ser carregados depois que o kernel do Maven for inicializado. Seria algo do tipo:

• As propriedades default do Plug-in são processadas
• ${project.home}/project.properties são processadas
• ${project.home}/build.properties são processadas
• ${user.home}/build.properties são processadas

Então, uma vez que os Plug-ins são processados tardiamente no ciclo de inicialização, você poderá sobrescrever qualquer propriedade default definida pelo plug-in. Por exemplo, o plug-in CheckStyle define a propriedade default, que segue abaixo:

maven.checkstyle.format = sun

Aqui, o plug-in CheckStyle, recebe a instrução de utilizar a convenção de código definida pela SUN, como formato default. Mas, você poderá sobrescrever esse valor em qualquer um dos arquivos de propriedades, descritos acima. Portanto, se você colocar o trecho, que segue abaixo, no arquivo: ${project.home}/project.properties, o plug-in CheckStyle passará a utilizar a convenção de código definida pelo Turbine.

maven.checkstyle.format = turbine

Behavioral Properties

Abaixo, a tabela apresenta a lista de propriedades que altera a forma com que o Maven trabalha:

<?xml version="1.0"?>

Utilizando Proxies

Se você estiver atrás de um proxy, o Maven irá obedecer as seguintes propriedades:

Se você precisa utilizar um proxy, o lugar mais apropriado para setar os valores dessas propriedades será no seu arquivo: ${user.home}/build.properties. Abaixo, segue um exemplo:

## ----------------------------------------------------------
## ${user.home}/build.properties
## ----------------------------------------------------------
maven.proxy.host = meu.servidorproxy.com.br
maven.proxy.port = 8080
maven.proxy.username = nomedousuario
maven.proxy.password = senha

Utilizando Múltiplos Repositórios Remotos

Você poderá especificar o uso de múltiplos repositórios remotos em qualquer um dos arquivos de propriedades processados pelo Maven, simplesmente, fazendo algo como o que segue abaixo:

maven.repo.remote = http://www.ibiblio.org/maven/,http://www.meusite.com.br/maven/

Projeto Agenda On-line

AgendaOnline	
	|- conf				- Diretório contendo alguns arquivos de configuração	
	|- maven.xml		- Utiliza o Maven Multiproject Plug-in	
	|- project.xml		- Template de definitpo do Projeto Master	
	|- AgendaWeb		- Sub-projeto que irá produzir o agenda-web.war	
	|	|- maven.xml	- Define as goals para o sub-projeto AgendaWeb	
	|	`- project.xml	- Definições do projeto AgendaWeb. Estende as definições do 
	|					  Projeto Master   
	|                         
	|- AgendaEAR		- Sub-projeto que irá produzir o agenda-online.ear	
	|	`- maven.xml	- Define as goals para o sub-projeto AgendaEAR	
	|	`- project.xml	- Definições do projeto AgendaEAR. Estende as definições do
	|					  Projeto Master	
	|
	|- AgendaEjb		- Sub-projeto que irá produzir o agenda-ejb.jar, um arquivo ejb jar
	|	|- maven.xml	- Define as goals para o sub-projeto AgendaEjb	
	|	`- project.xml	- Definições do projeto AgendaEjb. Estende as definições do
	|					  Projeto Master	
	|
	`- AgendaServices		- Sub-projeto que irá produzir o agenda-services.jar		
		|- maven.xml	- Define as goals para o sub-projeto AgendaServices		
		`- project.xml	- Definição das dependencias. Estende as definições do
						  Projeto Master	

Agora, iremos utilizar o Maven em um projeto J2EE. O artefato J2EE mais comum gerado e publicado é o EAR. Os componentes que podem ser empacotados dentro de um arquivo EAR não estão diretamente correlacionados com os componentes contidos nos containers. Não há nenhuma exigência do que deve ser minimamente incluso dentro de um arquivo EAR. Um arquivo EAR é composto de qualquer número dos seguintes componentes:

Figura 3 - J2EE Application

Master Project

Na Agenda On-line iremos utilizar o template apresentado na Figura 1 - Organização de um projeto simples utilizando o Maven -, item 1.1.3 (Criando um projeto simples com o Maven Application Generator Plug-in) desse tutorial. Na Listagem 13 acima, apresentamos o relacionamento entre os projetos, assim como sua hierarquia. O Master Project é definido no nível mais alto dos projetos. Um resumo do template do projeto master é apresentado abaixo (Listagem 15), contendo somente os elementos essenciais. No item 2 desse tutorial, você pode ver na íntegra todos os elementos do POM. É importante observar que as dependências não estão descritas nesse template. Isso se deve ao fato de que o master project é um template para os sub-projetos estenderem. A Listagem 14 apresenta a estrutura do arquivo EAR gerado por esse projeto. Você encontrará uma organização semelhante entre o conteúdo do EAR e o projeto J2EE com Maven, apresentado na Listagem 13. Na maioria dos projetos J2EE não teremos um artefato de distribuição muito diferente do apresentado na Listagem 14. E quando desviarmos dessa rota usual, os scripts de build "out-of-the-box" do Maven, trabalharão para que tudo funcione.

agenda-online-1.0-dev.ear	
	|- application.xml	
	|- xerces-1.4.4.jar	
	|- log4j-1.2.8.jar	
	|- agenda-services-1.0-dev.jar - EJB e WAR possuem o agenda-services.jar 
	|								 no seu CLASSPATH	
	|- agenda-ejb-1.0-dev.jar				
	|	` META-INF	
	|		` MANIFEST.MF  		   - WAR manifest file possui o agenda-ejb.jar no  
	|								 seu CLASSPATH
	|	
	`- agenda-web-1.0-dev.war					
		` META-INF			
			` MANIFEST.MF

<?xml version="1.0" encoding="ISO-8859-1"?>

<project>    
	<pomVersion>1</pomVersion>    
	<groupId>agenda-online</groupId>    
	<currentVersion>1.0-dev</currentVersion>    
	<name>Projeto Agenda Online</name>    

	<!-- ################################################################ -->    
	<!--        Seção de Gerenciamento do Projeto                         -->    
	<!-- ################################################################ -->    

	<organization>        
		<name>Néki Technologies</name>        
		<url>http://www.neki-technologies.com.br</url>        
		<logo>http://www.neki-technologies.com.br/imagens/logo_neki.gif</logo>    
	</organization>    
	<inceptionYear>2003</inceptionYear>    
	<package>br.com.neki.*</package>    
	<distributionDirectory>       
		${maven.repo.local}/${pom.groupId}/${pom.artifactId}/    
	</distributionDirectory>    

	<!-- ################################################################ -->    
	<!--        Seção de Dependências do Projeto                          -->    
	<!-- ################################################################ -->    

	<dependencies/>    

	<!-- ################################################################ -->    
	<!--        Seção de Construção do Projeto                            -->    
	<!-- ################################################################ -->    

	<build>        

		<nagEmailAddress>fabiano.cruz@neki-technologies.com.br</nagEmailAddress>        
		<sourceDirectory>${basedir}/src</sourceDirectory>       
		<unitTestSourceDirectory>${basedir}/test</unitTestSourceDirectory>        
		<unitTest>          
			<includes>            
				<include>**/Test*.java</include>          
			</includes>         
			<excludes>           
				<exclude>**/*Test*All.java</exclude>          
			</excludes>        
		</unitTest>        
		<resources/>  

		<!-- (OPTIONAL) Resources packaged inside the JAR file. -->    
	</build>    

	<!-- ################################################################ -->    
	<!--        Seção de Relatórios do Projeto                            -->   
	<!-- ################################################################ -->    

	<reports/>

</project>

Construindo o JAR de Serviço (Java Module)

A Listagem 16 apresenta a definição do projeto de Serviço - um sub-projeto no Maven. Esse sub-projeto cria o arquivo agenda-services-1.0-dev.jar - uma biblioteca de dependência utilizada por ambos, ejb e camada web. Repare na tag extends a referência ao template do Master Project, apresentado na Listagem 15. Por ter estendido o pai, todas as propriedades serão herdadas. Ele irá definir os elementos dependency, indicando suas dependências na API J2EE (que não foram definidas no pai) e irá sobrescrever o id, name e description definidos no pai.

<?xml version="1.0" encoding="ISO-8859-1"?>
<project>  
	<extend>${basedir}/../project.xml</extend>  
	<id>agenda-services</id>  
	<name>Agenda Services</name>  
	<package>br.com.neki.service.*</package>  
	<description>Servicos referentes ao Projeto Agenda Online</description>  
	<shortDescription>Agenda Services JAR</shortDescription>  
	<dependencies>     
		<dependency>        
			<groupId>j2ee</groupId>        
			<artifactId>j2ee</artifactId>        
			<version>1.3.1</version>     
		</dependency>  
	</dependencies>
</project>

Agora, vamos dar uma examinada no maven.xml do projeto Agenda Services. Tecnicamente falando, não precisaríamos fazer absolutamente nada para gerar o jar desse projeto, bastando executar maven jar:install na linha de comando. Entretanto, como veremos mais na frente, existirá um maven.xml que irá nos auxiliar, eliminando a execução manual do Maven para todos os sub-projetos. Portanto, o maven.xml do projeto Agenda Services, ficaria assim:

<project default="main" xmlns:m="jelly:maven">  
	<goal name="main">     
		<attainGoal name="jar:install" />  
	</goal>
</project>

Construindo o WAR (Web Module)

Depois do ejb jar, é hora do war. Gastaremos um tempinho a mais nessa seção. Primeiramente, iremos analisar o project.xml. Então, iremos adicionar uma funcionalidade básica, que ainda não existe no Maven WAR Plug-in. E por último, veremos como fica o arquivo maven.xml.

A Listagem 18 apresenta o project.xml da aplicação Web da Agenda. A atual definição do projeto possui muito mais dependências para serem baixadas. Aqui, iremos mostrar as partes relevantes para ilustrar os conceitos. A parte importante é a seção de dependências. A aplicação Web depende das APIs J2EE providas pelo container em tempo de compilação, assim como de execução. Entretanto, não há nenhuma necessidade de empacotar a API J2EE dentro do WAR, uma vez que isso é responsabilidade do servlet container. No mais, a aplicação web depende do JAR do Struts 1.1. Setando a propriedade <war.bundle>true</war.bundle>, indicará que o struts-1.1.jar será empacotado no WAR. Sempre que o WAR Plug-in receber a instrução de empacotar os jars, ele irá coloca-los dentro do diretório WEB-INF/lib do WAR. Comparado à cópia manual dos jars para o diretório WEB-INF/lib, pelo Ant. O WAR também depende do arquivo jar do Agenda Services, agenda-services-1.0-dev.jar. Entretanto, não queremos copiar o jar para o WEB-INF/lib, uma vez que o mesmo é uma biblioteca de dependência compartilhada por ambos, camada web e ejb. Dessa forma, teremos setada a propriedade war.bundle como false para o arquivo agenda-services-1.0-dev.jar. Você terá todas essas funcionalidades out of the box através do Maven WAR Plug-in.

<?xml version="1.0" encoding="ISO-8859-1"?>
<project>  
	<extend>${basedir}/../project.xml</extend>  
	<id>agenda-web</id>  
	<name>Aplicação Agenda Web </name>  
	<package>br.com.neki.web.*</package>  
	<description>Projeto Agenda Web</description>  
	<shortDescription>Agenda web project</shortDescription>  
	<dependencies>    
		<dependency>        
			<groupId>j2ee</groupId>        
			<artifactId>j2ee</artifactId>        
			<version>1.3.1</version>    
		</dependency>    
		<dependency>       
			<id>xdoclet+web-module</id>       
			<version>1.2b4</version>    
		</dependency>    
		<dependency>      
			<groupId>struts</groupId>      
			<artifactId>struts</artifactId>      
			<version>1.1</version>      
			<properties>        
				<war.bundle>true</war.bundle>      
			</properties>    
		</dependency>    
		<dependency>        
			<groupId>agenda</groupId>        
			<artifactId>agenda-services</artifactId>        
			<version>${pom.currentVersion}</version>        
			<properties>            
				<war.bundle>false</war.bundle>            
				<war.manifest.classpath>true</war.manifest.classpath>        
			</properties>    
		</dependency>  
	</dependencies>
</project>

Entretanto, o Maven WAR Plug-in não possui uma característica. Ele não possui a capacidade de setar o manifest classpath. Sem essa característica, você não poderá utilizar bibliotecas de dependência. Então, acrescentaremos esse característica no WAR Plug-in. Serão necessárias somente duas pequenas alterações. Abra o plugin.jelly do WAR Plug-in em: C:/Documents And Settings/<login-id>/.maven/plugins/maven-war-plugin-<version>-[SNAPSHOT]. Essas alterações devem ser feitas na goal de nome war. Coloque o código que segue abaixo, nessa goal.

<j:forEach var="dep" items="${pom.dependencies}">  
	<j:if test="${dep.getProperty('war.manifest.classpath')=='true'}">
		<j:set var="maven.war.classpath" value="${maven.war.classpath} ${dep.artifact}"/>  
	</j:if>
</j:forEach>

Esse código irá iterar em cima de cada dependência descrita no project.xml (identificada pelo pom.dependencies) e irá checar se o war.manifest.classpath está setado como true. Caso sim, ele irá adicionar o nome do artefato na propriedade denominada maven.war.classpath.

A segunda alteração que precisa ser feita é quando o manifest file é escrito. O manisfest file é criado pelo Ant Plug-in, executando uma goal chamada manifest. O código de criação do manifest é apresentado abaixo. É necessário inserir a linha em negrito para setar o atributo manifest classpath. Que irá utilizar a propriedade maven.war.classpath setada acima.

<ant:manifest>  
	<ant:attribute name="Built-By" value="${user.name}" />  
	<ant:attribute name="Class-Path" value="${maven.war.classpath}"/>  
	<ant:section name="${pom.package}">    
		<ant:attribute name="Specification-Title"   value="${pom.artifactId}" />    
		<ant:attribute name="Specification-Version" value="${pom.currentVersion}" />    
		<ant:attribute name="Specification-Vendor"  value="${pom.organization.name}" />  
	</ant:section>
</ant:manifest>

Simples, não é!? :) Espero que isso o estimule a criar seus próprios plug-ins, quando for necessário, ao invés de ficar adicionando, repetidamente, tarefas dentro de preGoals e posGoals.

Abaixo, segue o maven.xml:

<project default="main" xmlns:m="jelly:maven">  
	<goal name="main">    
		<attainGoal name="war:install"/>  
	</goal>
</project>

Construindo o EAR

Até agora, você viu como criar cada artefato individual que irá para dentro do EAR. Finalmente chegamos a última parte - construir o EAR propriamente dito. Você pode imaginar que o EAR deveria ser construído a partir da definição do projeto no topo da hierarquia, no nosso caso, na raiz do diretório AgendaOnline, uma vez que o EAR é um único artefato para todo o projeto. Entretanto, não é o caso. O EAR é construído como um artefato de um sub-projeto chamado ear (veja Listagem 13). Por que essa anomalia? Em primeiro lugar, o project.xml no nível do projeto AgendaOnline é um template para todos os outros sub-projetos estender. Se tivéssemos que especificar as dependências para construir o EAR, então, isso resultaria em uma dependência cíclica - aquela situação do ovo e da galinha - quando o template fosse estendido por outros sub-projetos. Se o template tivesse sido definido em outro lugar, provavelmente no nível mais alto, logo o project.xml do diretório AgendaOnline poderia produzir um EAR, porém o mesmo não seria utilizado como um template para o restante dos sub-projetos estenderem.

A Listagem 20 apresenta o project.xml para o projeto Agenda EAR. Na lista, você poderá ver as bibliotecas mais relevantes (que precisam de alguma explicação), o qual o ear depende.

01 <?xml version="1.0"?>
02 <project>
03  <extend>${basedir}/../project.xml</extend>
04  <id>agenda-online</id>
05  <name>Agenda EAR</name>
06  <description>Projeto Agenda EAR.</description>
07  <dependencies>
08        <dependency>
09            <groupId>j2ee</groupId>
10            <artifactId>j2ee</artifactId>
11            <version>1.3.1</version>
12        </dependency>
13      <dependency>
14            <groupId>xerces</groupId>
15            <artifactId>xerces</artifactId>
16            <version>1.4.4</version>
17            <properties>
18                <ear.bundle>true</ear.bundle>
19            </properties>
20        </dependency>
21        <dependency>
22            <groupId>${pom.groupId}</groupId>
23            <artifactId>agenda-services</artifactId>
24            <version>${pom.currentVersion}</version>
25            <properties>
26                <ear.bundle>true</ear.bundle>
27            </properties>
28        </dependency>
29        <dependency>
30          <groupId>${pom.groupId}</groupId>
31          <artifactId>agenda-web</artifactId>
32          <version>${pom.currentVersion}</version>
33          <type>war</type>
34          <properties>
35            <ear.bundle>true</ear.bundle>
36            <ear.appxml.ear.context-root>AgendaWeb</ear.appxml.ear.context-root>
37          </properties>
38        </dependency>
39  </dependencies>
40 </project>

• Linha 33 - Type = war indicando que trata-se de um arquivo war. Isso será setado no application.xml;
• Linha 36 - Coloca o context root para a aplicação web. Isso será setado no application.xml;

Maven Multiproject Plug-in

Através do Reactor podemos utilizar o Maven para controlar a construção de múltiplos projetos. O Reactor faz uso do pacote Werkz para determinar a ordem correta das dependências, definidas por cada projeto no seu respectivo POM. Essa ferramenta foi criada para encorajar a criação, ou refatoramento, de projetos em unidades menores, mais coerentes e discretas. O Reactor é ideal para a Programação Orientada a Componentes (Component Oriented Programming - COP), onde o sistema é compreendido em várias pequenas entidades que necessitam ser agregadas para formar o todo para ser distribuído.

O Reactor pode executar uma lista arbitrária de goals para qualquer conjunto de projetos especificado. Sendo assim, apesar do Reactor ter sido criado para o building, o mesmo poderá ser utilizado para a geração do site, ou para a geração de qualquer outro artefato escolhido.

Propriedades do Multiproject Plug-in:

CONFIGURAÇÕES

Uma das primeiras configurações é a criação de um simples navigation.xml, que conterá a estrutura do menu para navegar pela documentação. Para isso basta adicionar todos os itens e sub-itens que representem os arquivos HTML gerados a partir dos arquivos XML.

Os itens podem ser expandidos ou não, dependendo da sua navegação. Para isso adicione collapse="true" na declaração do item. Exemplo:

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Maven Xdoc Plugin">  
	<title>Maven Xdoc Plugin</title>  
	<body>    
		<menu>      
			<links>      
				<item name="Maven"  href="http://maven.apache.org/"/>
			</links>    
			<item name="Alpha" href="/alpha/index.html">
				<item name="Alpha One" href="/alpha/one/index.html"/>
				<item name="Alpha Two" href="/alpha/two/index.html"/>
			</item>
			<item name="Beta" href="/beta/index.html" collapse="true">
				<item name="Beta One" href="/beta/one/index.html" collapse="true"/>
				<item name="Beta Two" href="/beta/two/index.html" collapse="true"/>
			</item>
		</menu>
	</body>
</project> 

Para adicionar uma imagem a um item de navegação basta adicionar a opção img:

<item name="The Site" href="http://www.thesite.net/" img="http://www.thesite.net/thesite.png"/>

Podem ser adicionadas configurações para o Maven através do arquivo project.properties que se encontra em ${project.home}:

Organização das documentações geradas:

RELATÓRIOS

Através da utilização do Maven, vários relatórios podem ser gerados automaticamente, provendo conjunto de informações relevantes sobre o projeto, tanto para as equipes técnica, de qualidade ou gerencial. Isto é feito facilmente com a inclusão da tag reports no descritor do projeto. Mas o uso dessa tag não é obrigatório, onde a supressão de seu uso faz com que um conjunto de relatórios padrão seja gerado. Com essa tag, você pode incluir ou excluir determinados tipos de relatórios que são gerados com a utilização de plugins do Maven, todos esses são adicionados no menu de navegação na ordem em que são adicionados.

Esses relatórios são gerados através do comando maven site.

No project.xml:

<reports>    
	<report>maven-changes-plugin</report>    
	<report>maven-faq-plugin</report>    
	<report>maven-multiproject-plugin</report>  
</reports>

O adicionamento de um plugin chamado xyz para geração de um determinado relatório deve ser feito utilizando o seguinte valor na tag "report": maven-xyz-plugin.

O conjunto padrão de relatórios é definido no plugin xdoc o qual tem como valor padrão os seguintes plugins:

• maven-changelog-plugin
• maven-changes-plugin
• maven-checkstyle-plugin
• maven-developer-activity-plugin
• maven-file-activity-plugin
• maven-javadoc-plugin
• maven-jdepend-plugin
• maven-junit-report-plugin
• maven-jxr-plugin
• maven-license-plugin
• maven-linkcheck-plugin
• maven-pmd-plugin
• maven-tasklist-plugin

Caso seja desejado usar o conjunto padrão de relatórios, mas adicionar algum em especial, ou retirar algum, a melhor forma de fazer isso é usar postGoal para xdoc:register-reports.

<postGoal name="xdoc:register-reports">
     <attainGoal name="maven-changelog-plugin:deregister"/> 
	 <attainGoal name="maven-meu-plugin:register"/>
</postGoal>

A documentação dos sites que agregam um conjunto de subprojetos e que devem conter a inclusão completa da documentação do projeto como seções na barra de navegação de seus sites. Isto pode ser feito com a configuração da propriedade maven.xdoc.includeProjectDocumentation com o valor de "no". Por padrão o Maven icluirá a documentação do projeto na seção da barra de navegação com a qual incluirá informações sobre o projeto tão quanto links para os numerosos relatórios gerados pelo próprio Maven. //TODO: rever!

MAVEN XDOC PLUGIN

O plugin XDoc é o principal mecanismo utilizado para produzir a documentação do projeto gerado pelo Maven, tão quanto qualquer informações fornecida pela equipe no "xdocs". Um "xdoc" é um arquivo XML composto por pequenos e simples conjuntos de tags. O Maven utiliza esse formato por completo, onde os relatórios gerados são primeiramente gerados como um "xdoc", os quais então são transformados em HTML através desse plugin. Isso é feito com o uso de Jelly/JSL que transformam arquivos XML em HTML. Todos os arquivos XML existentes no diretório são convertidos utilizando JSL. Os arquivos que não são XML e/ou sub-diretórios são copiados sem modificação, com isso é permitido a inclusão de outros tipos de documentos (inclusão de imagens). Os arquivos HTML gerados automaticamente herdam o look-and-feel padrão do Maven.

Os arquivos XML devem ser compostos de sintaxe XML/XHTML que sejam passíveis de "parser" padrão para XML (Xerces).

Exemplo:

<?xml version="1.0"?>
<document>  
	<properties>    
		<author email="nospam.AT.foo.DOT.com">Jon S. Stevens</author>    
		<author email="mrsmith.AT.foo.DOT.com">Mr. Smith</author>    
		<title></title>  
	</properties>  
	<meta name="keyword" content="jakarta, java"/>
	<body>
		<section name="Section 1">  
			<p>This is section 1.</p>  
			<table>    
				<tr>      
					<td>This is a table</td> 
				</tr>  
			</table>
			<ul>      
				<li>This is an unordered list.</li>  
			</ul>
		</section>
		<section name="Section 2">  
			<p>This is section 2.</p>  
			<ol>      
				<li>This is an ordered list.</li>  
			</ol>
		</section>
		<section name="Section 3">  
			<p>This is section 3.</p>  
			<source>      
				Anything within this tag is rendered as a "box" with blue 
				lines and &lt;pre&gt;&lt;/pre&gt; tags around it.  
			</source>  

			<subsection name="Subsection of Section 3">    
				<p>This is the subsection 3.</p>  
			</subsection>
		</section>
	</body>
</document>

Explicando algumas coisas:

• É possível ter uma ou mais tags <author>
• É possível ter uma ou mais tags <section>
• Dentro da tag <section> é possível ter uma ou mais tags <p>. Qualquer tipo de texto deve estar entre tags <p> e pode conter outras marcações XHTML.
• Tag <meta> são colocadas como tags dentro da <document> e vão direto para o arquivo html.
• Tags <source> são especiais, existem somente dentro das tags <section> e <subsection>. Se estiver utilizando outras marcações XML/XHTML dentro das tags source, então é necessário utilizar CDATA. Exemplo:

  <source><![CDATA[conteúdo foo]]></source>

  No exemplo do arquivo xml, estamos utilizando a tag <pre> e podemos ver que esta não precisa estar em uma CDATA.

Você pode utilizar a tag footer para incluir texto ou imagens abaixo do menu de navegação e acima do aviso de copyright. Esta tag tem somente uso no arquivo navigation.xml e deve ser colocada dentro do elemento body. Exemplo:

<footer>      
	<A href="http://sourceforge.net/projects/ctecl">        
		<IMG src="http://sourceforge.net/sflogo.php?group_id=72748"
			border="0" alt="sf logo"/>      
	</A>   
</footer>

Se o elemento search é encontrado dentro do body do arquivo navigation.xml, uma opção de pesquisa é gerada no menu de navegação, a qual usará o google.

<project name="foo">  
	<body>     
		<menu name="bar">  ...  </menu>     
		<search/>  
	</body> 
</project>

Adicionando mais usabilidade aos xdocs, podem ser incluídos outros tipos de arquivos como imagens, arquivos HTML, PDF's etc. Por padrão este plugin copiará todos os arquivos localizados no diretório maven.docs.src para a geração final do site. Caso seja criado um style/project.css abaixo de maven.docs.src, ele será copiado para a árvore de documentos e importado para dentro de cada página (via @import). Isto permite você facilmente adicionar e modificar os styles providos pelo Maven.

EXEMPLOS DE REPORTS

Changes:

Com esse relatório você pode navegar por todo o site do projeto e ter um resumo de todas as alterações que ocorrem. Com isso as alterações que ocorrem diariamente, a cada dois dias ou semanalmente (a partir de suas configurações) podem ser acompanhadas e ver o que esta acontecendo de novo. Para habilitar esse relatório, é necessário criar o arquivo changes.xml no diretório xdocs. O formato para esse arquivo é o seguinte:

<?xml version="1.0"?>
<document>  
	<properties>    
		<title>Changes</title>
		<author email="vmassol@octo.com">Vincent Massol</author>
	</properties>
	<body>
		<release version="1.5" date="in CVS">
			<action dev="vmassol" type="add" due-to="Jason Robertson"
					due-to-email="Jason.Robertson@acs-inc.com">  
				Added Form-based authentication support (Submitted by Jason Robertson).
			</action>
			<action dev="vmassol" type="add">
				Added a <link href="howto_build.html">tutorial</link> that 
				explains how to build Cactus from the sources.
			</action>
			[...]    
		</release>
	</body>
</document>

O atributo "type" pode ser add, remove update ou fix.

Para adicionar esse relatório:

• maven-changes-plugin

Exemplo:

Developer Activity:

Identifica cada desenvolvedor e seu commits e arquivos alterados.

Para adicionar esse relatório:

• maven-developer-activity-plugin

Exemplo:

File Activity:

Identifica o nome do arquivo e a quantidade de vezes que ele foi alterado.

Para adicionar esse relatório:

• maven-file-activity-plugin

Exemplo:

Task List:

Identifica a classe, a quantidade de "TODO's" e os métodos com "TODO".

Para adicionar esse relatório:

• maven-tasklist-plugin

Exemplo:

MÉTRICAS

Durante o desenvolvimento de um produto de software, procedimentos de medição e análise de dados quantitativos permitem que se obtenha informações objetivas quanto à qualidade do produto em construção e possibilitam um controle preciso da evolução do projeto. No contexto de uma organização produtora de software, o uso de medições permite que se tenha um melhor conhecimento da eficácia do processo de desenvolvimento, através do acompanhamento quantitativo de diversos aspectos como produtividade, evolução da qualidade de produtos desenvolvidos, acurácia de estimativas, entre outros.

Em primeiro lugar, devido à quantidade e à complexidade dos fatores envolvidos no desenvolvimento de um software de grande porte, há tantos aspectos a serem medidos que torna-se necessário selecionar apenas um subconjunto restrito, de forma a viabilizar as atividades de coleta e análise. Sem uma política bem definida para definição desse subconjunto de métricas, a probabilidade de se escolher arbitrariamente as métricas mais adequadas é muito remota.

Uma vez modelado o processo de desenvolvimento e alguns conceitos utilizados na medição, é possível definir as medidas a serem coletadas. São definidas as medidas explícitas (obtidas diretamente), a partir das quais se pode construir medidas derivadas.

Um exemplo de medida explícita é o registro de defeitos. Um defeito pode ser definido como qualquer problema ou imperfeição encontrado em um produto ou artefato de software, cuja correção implique na alteração de pelo menos um artefato produzido. São considerados defeitos apenas os problemas decorrentes de erros cometidos por membros da equipe de desenvolvimento. Alterações de requisitos solicitadas pelo cliente ou usuário não são consideradas defeitos, sendo tratadas à parte.

Durante o ciclo de vida do projeto, devem ser registrados todos os defeitos encontrados.

EXECUTANDO TESTES UNITÁRIOS

//TODO

Instalação

Uma vez baixado, um plug-in é normalmente instalado no Eclipse fazendo um unzipping dos arquivos baixados e copiando o conteúdo dos mesmos para o diretório plug-ins e features do Eclipse. Nesse caso, o arquivo mevenide.update_0.0.1.jar deve ser unzipado dentro do diretório 'raiz' do Eclipse (ele automaticamente cairá no diretório de plug-ins e features), enquanto que os arquivos: org.mevenide.config_0.1.jar, org.mevenide.core_0.1.1.jar, org.mevenide.grabber_0.1.1.jar, org.mevenide.ui_0.1.1.jar, necessitam ser unzipado diretamente no sub-diretório plug-ins do Eclipse. Por ultimo, o arquivo org.mevenide.feature_0.1.1.jar, deverá ser unzipado diretamente no sub-diretório features do Eclipse. Por segurança, você deve fazer o unzip em um diretório temporário e copiar para um diretório apropriado dentro do Eclipse. Se o Eclipse estiver sendo executado, você precisará parar e restartar para que os plug-ins sejam reconhecidos.

Configurações

Antes de utilizarmos o MavenIDE, deveremos configurá-lo adequadamente. Faremos isso, através da página de preferências do Maven. Em Window > Preferences > Maven. Java Home, Maven Home e Maven repository são informações requeridas para executarmos com sucesso o MavenIDE.

Um template para o POM também poderá ser especificado. Ele será utilizado na como esqueleto na criação de novos POMs.

Se você quiser, também poderá checar a opção 'Check timestamp before syncronizing', que irá verificar o timestamp do project.xml ou .classpath do projeto. Isso irá prevenir problemas de sobrescrita de arquivos de configuração.

Por último, você poderá especificar uma goal default a ser executada para todos os projetos.

Figura 01 - Maven Preferences

Para executar scripts a partir do Eclipse, utilizando o MavenIDE, basta clicar com o botão direito do mouse no POM (Project Object Model - project.xml) e no 'MavenIDE Menu', clique na opção 'Run Maven...'. Como segue abaixo:

Figura 02 - MavenIDE Menu

Quando você seleciona a opção 'Run Maven...' do Maven menu, um wizard irá aparecer para que você coloque as informações relevantes no contexto da IDE (isso significa que, opções como -b, -h, -p, entre outras, não estão acessíveis). As propriedades de sistema poderão ser especificadas utilizando o botão 'Add'.

A caixa de texto na parte inferior do wizard poderá ser editada e nela iremos colocar as goals que serão executadas. A tabela é utilizada para passarmos propriedades do sistema para o Maven.

Figura 03 - Wizard de execução do Maven

Você também poderá utilizar o atalho do Eclipse, em Run > External Tools > Run As > Maven Project. Esse comando irá executar a goal default especificada na página de preferências.

Figura 04 - Atalho para execução do Maven

Podemos visualizar o output da operação na própria console de debug do Eclipse, dada a inexistência de uma console para o Mavenide (versão atual).

POM Synchronization

Mavenide POM Synchronization é basicamente uma única página, composta de dois elementos:

• Uma aba, onde o usuário irá especificar qual artefato será colocado dentro do POM;
• E a outra, permite que o usuário especifique toda o status das dependências existentes no POM