Maven 2 - Clicks de Fernando Anselmo

Transcrição

Maven 2
Maven é uma popular ferramenta de construção Open Source para
projetos corporativos Java, projetado para realizar a maior parte do
trabalho repetitivo de um processo de construção. Maven utiliza uma
abordagem declarativa, onde a estrutura do projeto e conteúdo são
descritos, em seguida, a abordagem é baseada em tarefas utilizando o
Ant ou outros montadores tradicionais. Isso ajuda a garantir os padrões
da empresa a nível de desenvolvimento e reduz o tempo necessário para
escrever e manter os roteiros de construção. A declarativa é uma
abordagem do ciclo de vida usada pelo Maven 1 é, para muitos, foi uma
ruptura radical com as técnicas mais tradicionais de construção, o Maven
2 foi ainda mais longe nesse sentido.
Versão 1.0
Apostila destinada ao curso com carga horária de 16 (dezesseis) horas
Curso Maven 2
Sumário
1. Project Object Model (POM)..................................................................................................4
Objetivos do Maven...............................................................................................................4
O que é POM?.......................................................................................................................5
Mínimo POM..........................................................................................................................5
Uma rápida visão geral estrutural..........................................................................................6
Relacionamentos POM......................................................................................................7
Informações sobre o Projeto..............................................................................................7
Configurações da Construção...........................................................................................7
Construção do Ambiente...................................................................................................7
2. Estrutura de Diretório.............................................................................................................9
3. Ciclo de Vida Maven............................................................................................................10
Um Ciclo de Vida é feito de Fases.......................................................................................10
Fases são Compostas de Metas..........................................................................................11
Configurar o Projeto para usar o Ciclo de Vida...................................................................12
Empacotando...................................................................................................................12
Ciclo de Vida de Referência................................................................................................13
Ciclo de Vida: Default......................................................................................................13
Ciclo de Vida: clean.............................................................................................................14
Ciclo de Vida: site................................................................................................................14
4. Dependências Transitivas....................................................................................................15
Mediação de Dependência..................................................................................................15
Gerenciamento de Dependência.........................................................................................15
Dependências Excluídas.................................................................................................16
Dependências Opcionais.................................................................................................16
Obter uma Lista de Dependência Transitiva no Maven.......................................................16
Âmbito de dependência.......................................................................................................16
5. Escopo das Dependências..................................................................................................18
6. Configurações......................................................................................................................20
Configuração do Repositório Local......................................................................................20
Configuração do Proxy ........................................................................................................20
Configuração da Resolução Paralela do Artefato ...............................................................21
Configuração de Segurança e Implantação .......................................................................21
7. Archetypes............................................................................................................................22
Usando um Archetype .........................................................................................................22
8. Plugins..................................................................................................................................24
Meta help..............................................................................................................................25
Parâmetros de Configuração ..............................................................................................26
Mapeamento de Objetos Simples ..................................................................................26
Mapeamento de Objetos Complexos .............................................................................26
Mapeamento de Coleções...................................................................................................27
Listas de mapeamento ...................................................................................................27
Mapas de mapeamento ..................................................................................................28
S G A S 9 1 0 , B l o c o D , sa l a s , 2 3 7 a 2 4 3 , M i x Pa r k S u l – A s a S u l , B ra s í l i a / D F
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
2 de 41
Curso Maven 2
Configurando os Plugins de Construção.............................................................................28
Usando a tag <executions>.............................................................................................28
Usando a tag <dependencies>........................................................................................31
Usando a tag <inherited>................................................................................................32
Configurando os Plugins de Relatório.................................................................................32
Usando a tag <reportSets>..............................................................................................33
Usando a tag <inherited>................................................................................................33
9. Profiles..................................................................................................................................35
Diferentes tipos de profile....................................................................................................35
Acionando profiles................................................................................................................35
Detalhes sobre a ativação de profiles.............................................................................36
10. Erros comuns.....................................................................................................................38
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
3 de 41
Curso Maven 2
1. Project Object Model (POM)
Maven, uma palavra “iídiche” que significa Acumulador de Conhecimentos, foi
originalmente concebido como uma tentativa de simplificar os processos de construção do
projeto Jakarta Turbine. Existiam diversos projetos, e cada projeto possui seu próprio script
do Ant (que tem a função de construir os arquivos) independentes e diferentes.
Deveria existir uma forma padrão de construir os projetos, possuir uma definição clara do
que consiste os projetos, uma maneira simples para publicar as informações sobre o projeto,
sendo esta uma maneira de compartilhar os arquivos JARs em vários projetos. Como
resultado surgiu uma nova ferramenta que foi utilizada para a construção e o gerenciamento
de qualquer projeto baseado em Java.
Objetivos do Maven
O principal objetivo do Maven é permitir que um desenvolvedor compreenda o completo
estado de um esforço de desenvolvimento no mais curto espaço de tempo. Para atingir este
objetivo, há várias áreas de preocupação que o Maven procura resolver, tais como:
•
Tornar o processo de construção mais fácil e intuitivo;
•
Fornecer um sistema de construção uniforme;
•
Fornecer informações sobre a qualidade de projeto;
•
Fornecer orientações para o desenvolvimento das melhores práticas; e
•
Permitir uma migração transparente para novas funcionalidades.
Maven fornece muita informação útil do projeto, que, em parte, é retirado do POM (Project
Object Model) e em parte gerada pelos fontes do seu projeto. Por exemplo, o Maven
permite:
•
Alterar os documentos (logs) criados diretamente a partir de controle de origem;
•
Percorrer as fontes referenciadas;
•
Permitir listas de discussão entre os desenvolvedores;
•
Gerar listas entre os plugins de dependência; e
•
Relatórios unitários de testes.
Como o Maven melhora o conjunto de informações fornecidas todo o restante será mais
transparente para os usuários. Outros produtos também podem fornecer plugins para
permitir um novo conjunto de informações sobre o projeto juntamente com as informações
padrões fornecidas pelo Maven, todos ainda com base no POM.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
4 de 41
Curso Maven 2
O que é POM?
O coração de um projeto no Maven 2 é o Modelo de Objeto de Projeto (ou POM). O POM
contém uma descrição detalhada do projeto, incluindo informações sobre o versionamento,
gestão de configuração, dependências, recursos de aplicações e testes, os membros da
equipe, estrutura, e muito mais. O POM é um arquivo no padrão XML (pom.xml), inserido no
diretório home do projeto. Um simples exemplo desse arquivo pode ser visto abaixo:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.javaworld.hotels</groupId>
<artifactId>X25Database</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>Início Rápido ao Maven</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
O POM é a unidade fundamental de trabalho do Maven. É um arquivo XML que contém
informações sobre o projeto e detalhes de configuração usados pelo Maven para construir o
projeto. Contém valores padrões para a maioria dos projetos. Exemplos para isso é o
diretório de compilação, o alvo ou o diretório de origem, que é src/main/java, o diretório de
origem de teste é src/main/teste, e assim por diante.
O POM foi renomeado na Versão 1 de project.xml para pom.xml na Versão 2. Em vez de
existir um arquivo maven.xml que contém as metas que podem ser executadas, essas
metas ou plugins são agora configuradas no arquivo pom.xml. Ao executar uma tarefa ou
meta, devemos observar o arquivo POM no diretório atual. O POM é lido e recebe as
informações da configuração necessária, em seguida, executa a meta.
As configurações que podem ser especificadas no POM são as dependências do projeto, os
plugins ou objetivos que podem ser executados, os perfis de construção, e assim por
diante. Outras informações como a versão do projeto, descrição, desenvolvedores, listas de
discussão também podem ser especificadas.
Mínimo POM
O requisito mínimo para um POM são os seguintes:
•
modelVersion - deve ser definido para 4.0.0
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
5 de 41
Curso Maven 2
•
groupId - o id do grupo do projeto.
•
artifactId - a identificação do artefato (projeto)
•
version - a versão do artefato sob a determinado grupo
Aqui está um exemplo:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>x25.com.tutorial</groupId>
<artifactId>meu-exemplo</artifactId>
<version>1</version>
</project>
POM exige que seu groupId, artifactId, version serem configurados. Estes três valores
formam o nome do projeto totalmente qualificado. Isto é realizado, na forma de
<groupId>:<artifactId>:<versão>. Quanto ao exemplo acima, seu nome artefato totalmente
qualificado é "x25.com.tutorial:meu-exemplo:1".
Se os detalhes de configuração não são especificadas, Maven utilizará seus padrões. Um
desses valores padrão é o tipo de embalagens. Cada projeto Maven tem um tipo de
embalagem. Se não estiver especificado no POM, então o valor padrão "jar" será usado.
Além disso, podemos ver que no POM mínimo, os repositórios não foram especificados. Ao
construir seu projeto usando o POM mínimo, este herda toda configuração dos repositórios.
Portanto, quando o Maven vê as dependências no POM mínimo, essas dependências serão
resolvidas a partir de http://repo.maven.apache.org/maven2.
Uma rápida visão geral estrutural
O POM é grande e complexo, portanto, quebrando-o em pedaços é mais fácil de entendê-lo.
As peças são agrupadas em quatro unidades lógicas, como mostrado na seguinte figura:
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
6 de 41
Curso Maven 2
Relacionamentos POM
Os projetos devem se relacionar de alguma forma. Desde a criação dos primeiros
montadores, projetos de software tiveram dependências; Maven introduziu formas de
relações até então não utilizadas para os projetos Java. Essas relações são coordenadas
pelo Maven, baseados em dependências, herança do projeto e agregação.
Informações sobre o Projeto
Informações do POM são extremamente úteis. A ideia é que são usada para relatórios, no
entanto, não automaticamente qualificá-los como configurações de compilação. Os
elementos de informação do projeto são utilizadas apenas como parte de um processo de
construção e sem se envolver ativamente configurá-lo.
Configurações da Construção
Na parte da Configurações da Construção é onde o POM se torna interessante, pois temos à
carne real dele. Metade do poder do Maven se situa dentro dos dois elementos construir e
relatórios. Dividido em quatro partes:
•
Packaging – Este elemento descreve ao Maven que objetivos vincular sob o ciclo de
vida e oferece uma dica do tipo do projeto. Se não for especificado, então tipo padrão
será jar.
•
Properties – Este elemento é utilizado em todo POM e encaixes do Maven como um
substituto para os valores. Quando uma propriedade é definida, pode-se usar o nome
da propriedade como um valor em forma de ${nome}, que será substituído pelo valor
definido em tempo de execução.
•
Build – Este elemento contém informações que descrevem como construir um projeto
é para prosseguir quando executado. Contém todos os tipos de informações úteis,
tais como onde as vidas de código fonte ou como plugins são configurados. Muita
dessas informações são herdadas. Como quase tudo no POM, pode-se substituir
esses padrões (embora geralmente não recomendado).
•
Reporting – O Maven define mais do que o padrão de construção do ciclo de vida.
Uma das ideias mais impressionantes vem do ciclo de vida de geração site.
Determinados plug-ins podem gerar relatórios definidos e configurado sob os
relatórios elementos, por exemplo, gerar relatórios no padrão Javadoc. Muito
parecido com a capacidade do elemento de construção para configurar plug-ins,
relatando comandos com a mesma capacidade.
Construção do Ambiente.
A maioria dos elementos aqui são descritivos do tipo de estilo de vida no qual um projeto
torna-se confortável. Elementos por nomes como ciManagement (Continuum,
CruiseControl), issueManagement (Bugzilla), scm (CVS, Subversion), e mailingLists (emails e arquivos) com todo o esboço dos programas e as configurações para a construção
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
7 de 41
Curso Maven 2
do sistema.
Como vimos, o Maven 2 POM é grande. Isso é, sem dúvida. No entanto, seu tamanho é
também prova de sua versatilidade. A capacidade de abstrair todos os aspectos de um
projeto em um único artefato poderoso. Longe estão os dias de dezenas de roteiros
diferentes de construção e documentação dispersa sobre cada projeto individual.
Junto com tudo que compõem o Maven 2 existe um bem definido ciclo de vida de
construção, escrita simplificada e manutenção dos plugins, repositórios centralizados, todo o
sistema com base em configurações, e um número crescente de ferramentas para tornar o
trabalho do desenvolvedor mais fácil de modo a manter projetos complexos.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
8 de 41
Curso Maven 2
2. Estrutura de Diretório
O Maven, possui uma estrutura de diretório comum, que permite quando os usuários
estiverem familiarizados com um projeto do Maven, imediatamente se sentirão confortáveis
com qualquer outro projeto Maven. As vantagens são análogas a adoção de um site – wide
– look and feel. A próxima seção documenta o layout de diretório esperada pelo Maven e o
diretório layout criado pelo Maven:
y
src/
main
/jav
a
Arquivos
fontes da
Aplicação /
Biblioteca
src/
main
/res
ourc
es
Recursos
Aplicação /
Biblioteca
src/
main
/fil
ters
Arquivos
de recursos
de filtro
src/
main
/ass
embl
Descritores
de
montagem
src/main/config
Arquivos de configuração
src/main/scripts
Aplicação / Biblioteca de scripts
src/main/webapp
Fontes da Aplicação Web
src/test/java
Programas fontes de teste
src/test/resources
Recursos de teste
src/test/filters
Arquivos de teste para recurso de filtro
src/site
Site do projeto
LICENSE.txt
Licença do Projeto
NOTICE.txt
Avisos e bibliotecas que o projeto depende
README.txt
Leia-me do Projeto
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
9 de 41
Curso Maven 2
Para os arquivos de alto nível descritivo do projeto, um arquivo pom.xml (e quaisquer
propriedades, maven.xml ou se estiver usando Ant build.xml). Além disso, existem
documentos textuais voltados para o que usuário seja capaz de compreender o projeto
imediatamente ao abrí-lo: README.txt, NOTICE.txt ou LICENSE.txt
Há apenas dois subdiretórios desta estrutura: src e target. Os outros diretórios que seriam
esperados aqui são metadados como CVS ou .svn, e quaisquer subprojetos em uma
compilação multi projeto (cada um dos quais seriam definidos como acima). O diretório
target é usado para abrigar toda a produção da construção.
O diretório src contém todo o material fonte para a construção do projeto, site e assim por
diante. Contém um subdiretório para cada tipo: main para o artefato principal de construção,
test para as unidades de teste e de recursos e site. Dentro de diretórios artefato produtoras
de origem (ou seja, principal e teste), há um diretório para a linguagem Java (em que a
hierarquia existe pacote normal), e outro para os recursos (a estrutura que é copiado para o
destino classpath dada a definição de recurso padrão). Se existem outras fontes que
contribuem para construir o projeto, que seriam em outros subdiretórios, como por exemplo
“src/main/antlr” conteria os arquivos de definição ANTLR.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
10 de 41
Curso Maven 2
3. Ciclo de Vida Maven
O Maven 2.0 é baseado no conceito central de um ciclo de vida de construção. O que isto
significa é que o processo para construir e distribuir um artefato particular (projeto) é
claramente definida. Para o desenvolvedor que constrói um projeto, isso significa que só é
necessário conhecer um pequeno conjunto de comandos para construir qualquer projeto
Maven, e o POM assegura que se obtenha os resultados desejados.
Há três built-in para construir os ciclos de vida:
•
default – lida com a implantação do projeto
•
clean – lida com a limpeza do projeto
•
site – lida com a criação da documentação do projeto.
No Maven 2, esta noção é padronizada em um conjunto conhecido e definido, entre as fases
do ciclo de vida. Em vez de invocar plug-ins, o desenvolvedor invoca uma fase do ciclo de
vida, por exemplo, $mvn compile.
Um Ciclo de Vida é feito de Fases
Cada um dos ciclos de vida é definido por uma lista diferentes de fases, no qual uma fase de
construção representa uma fase no ciclo de vida. Por exemplo, o ciclo de vida default possui
as seguintes fases:
•
validate – validar o projeto e disponibiliza todas as informações necessárias.
•
compile – compilar o código fonte do projeto.
•
test – testar o código-fonte compilado usando um framework de testes unitário
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
11 de 41
Curso Maven 2
adequado. Estes testes não devem exigir que o código seja compilado ou implantado.
•
package – empacotar o código compilado em seu formato distribuível, como um JAR.
•
integration-test – processar e implantar o pacote se necessário em um ambiente
onde os testes de integração podem ser executados.
•
verify – executar todos os controles para verificar se o pacote é válido e atenda aos
critérios de qualidade.
•
install – instalar o pacote no repositório local, para uso como uma dependência em
outros projetos localmente.
•
deploy – copiar o pacote final para o repositório remoto para compartilhar com outros
desenvolvedores e projetos, realizado em um ambiente de integração ou de release.
Estas fases de construção são executados sequencialmente para completar o ciclo de vida
default. Significa que quando o ciclo de vida default for usado, o Maven primeiro valida o
projeto, compila os fontes, executa os testes, processa o pacote binário (por exemplo, jar),
executa os testes de integração, verifica o pacote, instala o pacote verificado para o
repositório local, e, em seguida, implanta o pacote instalado em um ambiente específico.
Para realizar tudo, só é necessário chamar a última fase de construção e executá-la, neste
caso, deploy:
mvn deploy
Isso porque ao chamar uma fase de construção, será executado todas as fases que esta
depende. Desta forma, ao ser executado o comando:
mvn integration-test
Todas as fases de construção antes de executar a integração de teste (validar, compilar
pacotes, etc) serão realizadas.
Há mais comandos que fazem parte do ciclo de vida, o que será discutido nas secções
seguintes. Também deve ser observado que o mesmo comando pode ser usado em um
cenário multi-módulo (isto é, um projecto com um ou mais subprojetos). Por exemplo:
mvn clean install
Este comando percorre todos os subprojetos e executa uma limpeza, em seguida, instala
incluindo todas as etapas anteriores.
Fases são Compostas de Metas
No entanto, apesar de uma fase de construção ser responsável por um passo específico no
ciclo de vida de construção, a maneira pela qual são realizas as responsabilidades pode
variar. E isso é feito, declarando as metas vinculadas a essas fases de construção.
Uma meta representa uma tarefa específica (mais específica do que uma fase de
construção), que contribui para a construção e gestão de um projeto. Pode ser ligado a zero
ou mais fases de construção. Uma meta não está vinculada a qualquer fase de construção e
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
12 de 41
Curso Maven 2
pode ser executada fora do ciclo de vida de construção por uma invocação direta. A ordem
de execução depende da ordem no qual a(s) meta(s) da(s) fase(s) de construção e(são)
chamada(s). Por exemplo, considere o seguinte comando:
mvn clean dependency:copy-dependencies package
clean e package são fases enquanto que dependency:copy-dependencies é uma meta.
Quando executado, a fase clean será realizada em primeiro lugar (o que significa que vai
executar todas as fases precedentes do ciclo de vida), e, em seguida, a meta
dependency:copy-dependencies, e finalmente a fase package (e todo o ciclo de vida
precedente).
Se uma meta está ligada a uma ou mais fases de construção, será chamado as metas em
todas as fases. Além disso, uma fase pode também ter zero ou mais metas ligadas a ele. Se
uma fase de construção não tem metas vinculadas, a fase não será executada. Mas se tiver
uma ou mais metas vinculados a fase, irá executar todas essas metas.
Configurar o Projeto para usar o Ciclo de Vida
O ciclo de vida é muito simples de usar, ao construir um projeto no Maven, devemos
proceder a atribuição das metas a cada uma das seguintes fases.
Empacotando
A primeira forma, e mais comum, é definir um pacote para o seu projeto através do elemento
de POM denominado <packaging>. Alguns dos valores válidos são pacotes jar, war, ear e
pom. Se nenhum valor do pacote for especificado, o padrão será jar.
Cada pacote contém uma lista de objetivos para se ligar a uma fase particular. Por exemplo,
o pacote irá vincular as seguintes metas para a construção das fases do ciclo de vida
default.
process-resources
resources:resources
compile
compiler:compile
process-test-resources
resources:testResources
test-compile
compiler:testCompile
test
surefire:test
package
jar:jar
install
install:install
deploy
deploy:deploy
Este é um conjunto padrão de ligações, no entanto, alguns pacotes podem lidar de forma
diferente. Por exemplo, um projeto que é puramente metadados (valor do pacote é pom) só
liga as metas para as fases install e deploy.
Observe que, para alguns tipos de pacote estajam disponíveis, precisamos incluir um plugin
na seção <build> do seu POM e especificar <extensions>true</extensions> para esse
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
13 de 41
Curso Maven 2
plugin. Um exemplo de um plugin é o Plexus, que fornece um pacote plexus-application e
plexus-service.
Ciclo de Vida de Referência
Vejamos uma lista para todas as fases do ciclo de vida: default, clean e site, que são
executados na ordem dada até o ponto que foi especificado.
Ciclo de Vida: Default
validate
Verificar se o projeto está correto e todas as informações
necessárias disponíveis
initialize
Inicializar o estado de construção do projeto, por exemplo,
define as propriedades ou cria os diretórios necessários
generate-sources
Gerar qualquer código-fonte para a inclusão na compilação
process-sources
Processar o código fonte, por exemplo, para filtrar quaisquer
valores
generate-resources
Gerar recursos para a inclusão no pacote
process-resources
Copiar e processar, os recursos para o diretório destino,
prontos para o empacotamento
compile
Compilar o código fonte do projeto
process-class
Pós-processar os arquivos gerados a partir da compilação,
por exemplo, criar os bytecodes para as classes Java
generate-test-sources
Gerar qualquer código fonte de teste para inclusão na
compilação
process-test-sources
Processar o código-fonte de teste, por exemplo, para filtrar
quaisquer valores
generate-test-resources Criar recursos para o teste
process-test-resources
Copiar e processar, os recursos para o diretório de destino de
teste
test-compile
Compilar o código fonte de teste no diretório de teste do
destino
process-test-compile
Pós-processar os arquivos gerados a partir da compilação de
teste, por exemplo, os bytecode em classes Java. Para
Maven 2.0.5 ou superior
test
Executar os testes usando um framework de teste unitário
adequado. Estes testes não devem exigir o código ser
empacotado ou implantado
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
14 de 41
Curso Maven 2
prepare-package
Realizar todas as operações necessárias para preparar um
pacote antes da embalagem real. Isso geralmente resulta em
uma versão descompactada, processados do pacote (Maven
2.1 ou superior)
package
Obter o código compilado e empacotá-lo em seu formato
distribuível, como um jar
pre-integration-test
Executar as ações necessárias antes dos testes de
integração serem executados. Isto pode envolver coisas
como a criação do ambiente necessário
integration-test
Implantar o processo necessário em um ambiente onde os
testes de integração podem ser executados
post-integration-test
Executar as ações necessárias após os testes de integração
serem executados. Isso pode inclusive realizar uma limpeza
no ambiente
verify
Executar todos os controles para verificar se pacote é válido
e atende aos critérios de qualidade
install
Instalar o pacote no repositório local, para uso como uma
dependência em outros projetos localmente
deploy
Copiar o pacote final para o repositório remoto, realizado no
ambiente de integração ou de release, para compartilhar com
os outros desenvolvedores e projetos
Ciclo de Vida: clean
pre-clean
Executar os processos necessários antes do processo de limpeza
clean
Remover todos os arquivos gerados pela compilação anterior
post-clean
Executar os processos necessários para finalizar o processo de limpeza
Ciclo de Vida: site
pre-site
Executar os processos necessários antes da geração do projeto
site
Gerar a documentação do projeto
post-site
Executar os processos necessários para finalizar a geração, e se preparar
para a implantação
site-deploy
Implantar a documentação do site gerado para o servidor Web
especificado
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
15 de 41
Curso Maven 2
4. Dependências Transitivas
A gestão de dependência é uma das características da Maven que é mais conhecida sendo
uma das áreas onde este se destaca. Não há muita dificuldade em gerir as dependências de
um único projeto, mas ao lidar com projetos e aplicações multi módulos que consistem de
dezenas ou centenas de módulos, o Maven será uma ferramenta imprescindível na
manutenção de um elevado grau de controle e estabilidade.
Dependências transitivas são um novo recurso no Maven 2.0. Permite evitar a necessidade
de descobrir e especificar as bibliotecas que suas próprias dependências exigem, e incluí-los
automaticamente. Este recurso é facilitado através da leitura dos arquivos de projeto de suas
dependências dos repositórios remotos especificados.
Em geral, todas as dependências desses projetos são usados no projeto, assim como
qualquer outra que o projeto herda de seus pais, ou de suas dependências, e assim por
diante. Não existe um limite para o número de níveis que as dependências podem ser
colhidos, e só vai causar um problema se uma dependência cíclica é descoberto. Com
dependências transitivas, o gráfico de bibliotecas incluídas pode rapidamente crescer
bastante. Por esta razão, há alguns recursos adicionais que limitam quais dependências
estão incluídos.
Mediação de Dependência
É o que determina qual a versão de uma dependência que será usada quando várias
versões de um artefato forem encontrados. Atualmente, Maven 2.0 suporta o uso de "a
definição mais próxima", que significa que usará a versão mais próxima da dependência ao
projeto na árvore de dependências. Sempre podemos garantir uma versão, declarando-o
explicitamente no POM do projeto. Observe que, se duas versões de dependência estão na
mesma profundidade na árvore de dependência, até Maven 2.0.8 não foi definido qual seria,
mas desde o Maven 2.0.9 é a ordem na declaração que conta.
"A Definição Mais Próxima" significa que a versão utilizada será a mais próxima do projeto
na árvore de dependências, por exemplo. se as dependências de A, B e C são definidas
como por exemplo: A → B → C → D 2.0 e A → E → D 1.0, então D 1.0 será utilizado na
construção porque o caminho de A para D através de E é mais curto. Podemos adicionar
explicitamente uma dependência para D 2.0 em A para forçar seu uso.
Gerenciamento de Dependência
Permite que os autores do projeto especifiquem diretamente as versões dos artefatos a
serem usados quando são encontrados em dependências transitivas ou em dependências
onde nenhuma versão for especificada. No exemplo da secção anterior de uma dependência
que foi diretamente adicionada a uma, mesmo que não seja diretamente utilizado por A. Em
vez disso, A pode incluir D como uma dependência na sua seção dependencyManagement e
controlar diretamente qual a versão de D será utilizada quando, ou se, for referenciada.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
16 de 41
Curso Maven 2
No âmbito de dependência lhe permite incluir apenas as dependências adequadas para a
fase atual da construção.
Dependências Excluídas
Se o projeto X depende do projeto Y, e o projeto Y depende do projeto Z, o dono do projeto X
pode excluir explicitamente o projeto Z como uma dependência, usando o elemento
"exclusion".
Dependências Opcionais
Se o projeto Y depende do projeto Z, o proprietário do projeto Y pode marcar o projeto
como uma dependência opcional, usando o elemento "optional". Quando o projeto
depende do projeto Y, X dependerá apenas Y, e não da dependência opcional do projeto
em Z. O dono do projeto X pode então adicionar explicitamente uma dependência para
projeto Z.
Z
X
Y
o
Obter uma Lista de Dependência Transitiva no Maven
Ao necessitar encontrar a lista de dependências transitivas, de modo a excluir dependências
desnecessárias. Adicione o seguinte plugin ao Maven:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
</plugins>
</build>
Use a meta dependency:tree:
mvn clean install dependency:tree
Âmbito de dependência
Utilizado para limitar a transitividade de uma dependência, e também afeta o classpath
utilizado para as diversas tarefas de construção. Existem seis escopos disponíveis:
•
compile – é o escopo padrão, usado se nenhum outro for especificado.
Dependências de compilação estão disponíveis em todos os caminhos da classe de
um projeto. Além disso, as dependências são propagadas para projetos dependentes.
•
provided – similar ao escopo “compile”, porém indica que esperamos que o JDK ou
um contêiner forneça a dependência em tempo de execução. Por exemplo, ao
construir um aplicativo Web para a plataforma Java EE, devemos definir a
dependência da API Servlet e API Java EE relacionadas ao âmbito previsto porque o
contêiner Web fornece essas classes. Esta aplicação está disponível apenas para a
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
17 de 41
Curso Maven 2
compilação e teste do classpath, e não é transitiva.
•
runtime – indica que a dependência não é necessária para a compilação, mas para a
execução. Classpaths são usados em tempo de execução e teste, mas não em tempo
de compilação.
•
test – indica que a dependência não é necessária para a utilização normal da
aplicação, e está disponível apenas para a compilação de teste e fases de execução.
•
system – semelhante ao “provided”, exceto que devemos fornecer o JAR que o
contém explicitamente. O artefato está sempre disponível.
•
import (disponível apenas em Maven 2.0.9 ou posterior) – usado apenas em uma
dependência do tipo POM na seção <dependencyManagement>. Indica que o POM
especificado deve substituir as dependências do POM. Uma vez que as
dependências são substituídas, o escopo “import” não participa na limitação da
transitividade de uma dependência.
Cada um dos escopos (exceto para “import”) afeta as dependências transitivas de diferentes
maneiras.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
18 de 41
Curso Maven 2
5. Escopo das Dependências
Dependências estão definidas na POM, e pode ser resolvido transitivamente. No entanto,
não é necessário todas as dependências em todas as situações. É por isso que
dependências podem ter um escopo definido. Além disso, existe a tag que se pode usar para
uma dependência.
<opcional>true</optional>
Observamos o comportamento de cada escopo em diferentes metas. Falamos que o projeto
atual pode possuir uma dependência e um projeto do usuário. O projeto atual é o projeto
cujo o POM estamos editando. A dependência é um projeto que depende diretamente do
usuário. Um projeto do usuário é um projeto que o projeto atual possui uma dependência
direta. Consequentemente, um usuário tem um projeto com dependência indireta sobre a
dependência. Também podemos presumir um mecanismo maven2-based (meta) para
executar os projetos finais. As seguintes fases do ciclo de vida são importantes:
•
compile: Compilar a principal fonte.
•
test: compilar o código fonte de teste e executar os testes. Isto requer a principal
fonte para ser compilado (o objetivo de teste depende do objectivo de compilação).
•
run: (não existente) objetivo que executa um artefato final. Obviamente, isto requer as
principais fontes para ser compilado (o objetivo executar depende do objectivo de
compilação).
•
assembly: Criar um montador com todos os tipos de detalhes necessários para o
artefato. Entre outros, este pode conter uma lib que contém bibliotecas externas do
projeto atual depende.
Além disso, é importante ver que algumas dependências que são necessárias para a
compilação (e testes), são opcionais para o uso do artefato em um projeto de usuário ou
para executá-lo se ele é um projeto final em si. Exemplos disso são a dependência da
exploração sobre o log4j-commons, hibernate, ehcache e c3po. Estes projetos ou
codificados de tal maneira que eles detectar se ou não uma biblioteca está disponível no
classpath, e usá-lo, se for, mas não é necessário.
Além disso, dependências indiretas não são necessariamente necessários para compilar um
projeto do usuário: o projeto atual pode depender da dependência internamente, mas não
mencionar a dependência em sua API que é usado pelo projeto do usuário. Assim, a
dependência não é necessário para compilar o projeto do usuário, mas pode ser pela
execução do projeto final. Os seguintes escopos de dependência são suportados:
•
compile: Esta dependência é necessária para a compilação do fonte principal
•
test: Esta dependência é necessária para compilar e executar os testes. Não é
necessário para compilar o fonte principal ou executar o artefato final
•
runtime: Esta dependência é necessária para o funcionamento do artefato final. Não
é necessária para a elaboração do fonte principal, compilar ou executar os testes
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
19 de 41
Curso Maven 2
•
provided: Esta dependência é necessária para compilar ou executar o artefato, mas
não é necessária para incluir no pacote, porque é fornecida pelo ambiente de
execução – por exemplo, jsp-api.jar é fornecido pelo contêiner Web, de modo que
não é necessário incluí-lo na pasta WEB-INF/lib
•
system: Esta dependência é necessária em alguma fase do ciclo de vida do seu
projeto, mas é um sistema específico. O uso deste escopo é desencorajado: É
considerado como uma espécie de recurso "avançado" que só deve ser usado
quando realmente compreender todas as implicações de seu uso, que pode ser
extremamente difícil se não impossível de quantificar.
O escopo “system”, por definição, torna a construção não portátil. Pode ser necessário em
certos casos. Este escopo inclui o elemento <systemPath> que aponta para a localização
física desta dependência de máquina local. É, portanto, utilizado para se referir a algum
artefato que deve estar presente na máquina local e não em um repositório; cujo caminho
pode variar de máquina para máquina. O elemento <systemPath> pode se referir a
variáveis de ambiente em seu caminho, tal como ${JAVA_HOME} por exemplo.
tag <optional />
Para o projeto atual:
Fase
Escopo
compile
test
run
assembly
compile
U
U
U
U
test
!
U
!
!
runtime
!
U
U
U
provided
U
!
!
!
Para um projeto de usuário que tem o projeto atual como uma dependência de compilação
com escopo:
Fase
compile
test
run
assembly
U!O
U!O
U!O
U!O
test
!
U
!
!
runtime
!
U!O
U!O
U!O
provided
U!O
!
!
!
Escopo
compile
Legenda:
U
Faça o download, use a dependência no classpath e inclua a dependência na montagem.
O!U
Faça o download, use dependência no classpath, a menos que a dependência seja <optional />. E inclua a dependência na
montagem, a menos que a dependência seja <optional />.
!
Dependência não é usada
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
20 de 41
Curso Maven 2
6. Configurações
A configuração do Maven ocorre em 3 níveis:
•
Project – configuração mais estática ocorre no arquivo pom.xml
•
Installation – esta é a configuração é adicionada para uma instalação Maven
•
User – esta é a configuração específica para um determinado usuário
A separação é bastante clara – Project define as informações que se aplica ao projeto, não
importa quem o está construindo, enquanto os outros perfis definem as configurações para o
ambiente atual.
Nota: a configuração Installation e User não podem ser utilizadas para adicionar
informações sobre o projeto compartilhado, por exemplo, definir <organization> ou
<distributionManagement> para toda a empresa. Para isso, devemos ter os projetos
herdados de um pom.xml pai de toda a empresa. Podemos especificar a configuração do
usuário em ${user.home}/.m2/settings.xml. Devemos observar que o arquivo de
configuração não é obrigatório, a configuração default será utilizada caso o arquivo não seja
encontrado.
Configuração do Repositório Local
A localização do repositório local pode ser modificada na configuração do usuário. O valor
padrão é ${user.home}/.m2/repository/.
<settings>
...
<localRepository>/path/to/local/repo/</localRepository>
...
</settings>
Configuração do Proxy
A configuração de um proxy também pode ser especificado no arquivo de configurações.
Podemos configurar um proxy para usar alguns ou todos os requests HTTP. O nome de
usuário e senha são necessários apenas se o proxy requer autenticação básica. Note que
versões posteriores pode apoiar e armazenar senhas em um armazenamento seguro de
chaves – no médio prazo. Certifique-se que o arquivo settings.xml (inserido em $
{user.home}/.m2/settings.xml) esta amarrado com as permissões adequadas para o
sistema operacional. A configuração nonProxyHosts aceita “wild cards” (curingas), e cada
host é separado pelo caractere |. Combina com o equivalente de configuração do JDK.
<settings>
...
<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
21 de 41
Curso Maven 2
<host>proxy.somewhere.com</host>
<port>8080</port>
<username>proxyuser</username>
<password>somepassword</password>
<nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
</proxy>
</proxies>
...
</settings>
Configuração da Resolução Paralela do Artefato
Por padrão, o Maven 2.1.0 ou superior, consegue baixar até 5 artefatos de grupos diferentes
simultaneamente. Para alterar o tamanho deste pool de thread, inicie o Maven configurando
o valor para o atributo -Dmaven.artifact.threads. Por exemplo, para baixar apenas três
artefatos de cada vez:
mvn -Dmaven.artifact.threads=1 clean install
Podemos configurar esta opção de forma permanente, para isso utilizamos a variável de
ambiente MAVEN_OPTS. Por exemplo:
export MAVEN_OPTS=-Dmaven.artifact.threads=3
Configuração de Segurança e Implantação
Os repositórios que são utilizados para implantar um projeto são definidos na seção
<distributionManagement>. No entanto, não é aconselhável colocar o nome de usuário,
senha ou outras configurações de segurança nesse projeto. Por essa razão, devemos
adicionar uma definição de servidor para as suas próprias definições com um id que
corresponde à implantação do repositório do projeto. Além disso, alguns depósitos podem
exigir a autorização para baixar a partir de. Por isso as configurações correspondentes
podem ser especificadas em um elemento de servidor da mesma maneira. Quais
configurações são necessárias dependerá do tipo de repositório que estamos implantando. A
partir do primeiro lançamento, apenas implantações SCP e implantações de arquivos são
suportados por padrão, portanto, apenas a configuração SCP são necessárias:
<settings>
...
<servers>
<server>
<id>repo1</id>
<username>repouser</username>
<password>senha</password>
<privateKey>/path/to/identity</privateKey> (default is ~/.ssh/id_dsa)
<passphrase>frase lembrança</passphrase>
</server>
...
</servers>
...
</settings>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
22 de 41
Curso Maven 2
7. Archetypes
Um Archetype (Arquétipo) é um projeto Maven Templating Toolkit. Archetype é definido
como um padrão original ou modelo a partir do qual todas as outras coisas do mesmo tipo
são feitos. Os nomes se encaixam como estamos tentando fornecer um sistema que fornece
um meio consistente de geração para os projetos Maven.
Isso ajuda os desenvolvedores a criar modelos de projeto do Maven para os usuários, e
oferece aos usuários os meios para gerar versões parametrizadas desses modelos de
projeto.
O uso de Archetypes proporciona uma boa maneira de permitir rapidamente que os
desenvolvedores de uma forma consistente empregar as melhores práticas por seu projeto
ou organização. Dentro do projeto Maven usamos Archetypes para tentar conseguir nossos
usuários em funcionamento o mais rapidamente possível, proporcionando um projeto de
exemplo que demonstra muitas das características do Maven, introduzir novos usuários para
as melhores práticas empregadas pelo Maven.
Em questão de segundos um novo usuário pode ter um projeto Maven pronto para usar
como trampolim de modo a investigar novos recursos. Também podemos criar um
mecanismo adicional ao Archetype e por isso entendemos que permite partes de um projeto
a ser capturado em um outro Archetype de modo que as partes ou aspectos de um projeto
podem ser adicionados a outros projetos existentes.
Um bom exemplo disso é o Archetype do site do Maven. Se já usou o Archetype “quick
start” para gerar um projeto de trabalho no qual se pode rapidamente criar um site para que
o projeto usando o Archetype do site dentro desse projeto existente. Também não
precisamos fazer nada parecido com os Archetypes.
Ao padronizar o desenvolvimento Java EE dentro de sua organização de modo que
podemos fornecer Archetypes para os EJB, ou WAR, ou para os seus Web Services. Uma
vez que esses Archetypes são criados e implantados no repositório da sua organização
estão disponíveis para utilização por todos os desenvolvedores em sua organização.
Usando um Archetype
Para criar um novo projeto baseado em um Archetype, é necessário chamar a meta mvn
archetype:generate, como o seguinte codificação:
mvn archetype:generate
Maven fornece vários artefatos:
Archetype ArtifactIds
Descrição
maven-archetype-archetype
Contém uma amostra de um simples arquétipo
maven-archetype-j2ee-simple
Contém uma amostra Simplificado aplicação Java EE
maven-archetype-mojo
Contém uma amostra de uma amostra plugin Maven
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
23 de 41
Curso Maven 2
maven-archetype-plugin
Contém uma amostra plugin Maven
maven-archetype-plugin-site
Contém um exemplo do site do plugin Maven
maven-archetype-portlet
Contém uma amostra JSR-268 Portlet
maven-archetype-quickstart
Contém uma amostra projeto Maven
maven-archetype-simple
Contém um projeto Maven simples
maven-archetype-site
Contém um site Maven amostra que demonstra alguns
dos tipos de documentos suportados como APT, xdoc,
e FML e demonstra como a i18n seu site
maven-archetype-site-simple
Contém uma amostra de um site Maven
maven-archetype-webapp
Contém uma amostra de um projeto webapp Maven
Arquétipos são empacotados em um JAR e consistem nos Archetypes metadados que
descreve o conteúdo do arquétipo e um conjunto de modelos do Velocity que compõem o
projeto de protótipo.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
24 de 41
Curso Maven 2
8. Plugins
No Maven, existe os plugins de construção e de relatórios:
•
Plugins de Construção: são executados durante a compilação e, em seguida,
devem ser configurados no elemento <build/>.
•
Plugins de Relatório: são executados durante a geração local e devem ser
configurados no elemento <reporting/>.
Todos plugins devem ter o mínimo de informações necessárias: groupId, artifactId e
version. Recomenda-se sempre definir cada versão dos plugins utilizados pela construção
de modo a garantir a reprodutibilidade da construção.
Uma boa prática é inseri-los nos elementos <build><pluginManagement/></build> para
cada plugin de construção (em geral, definimos um elemento <pluginManagement/> em um
POM). Para os plugins de relatório, devemos especificar cada versão no elemento
<reporting><plugins/></reporting>.
A configuração genérica dos plugins (compilação e comunicação) são especificados em um
elemento <configuration> onde os elementos filhos do elemento <configuration> são
mapeados para os campos, ou métodos SET padrão, dentro do Mojo (lembre-se que um
plug-in consiste em um ou mais Mojos onde alguns mapas Mojo servem para um objetivo).
Digamos, por exemplo, tivemos um Mojo que realiza uma consulta em uma URL específica,
com um tempo limite especificado e lista de opções. Um Mojo pode se parecer com o
seguinte:
public class MyQueryMojo extends AbstractMojo {
private String url; // expression="${query.url}"
private int timeout; // default-value="60"
private String[] options;
public void execute() throws MojoExecutionException {
...
}
}
Para configurar o Mojo de seu POM com a URL desejada e tempo de espera, e as opções
que podemos utilizar se parecem com:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-myquery-plugin</artifactId>
<version>1.0</version>
<configuration>
<url>http://www.foobar.com/query</url>
<timeout>10</timeout>
<options>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
25 de 41
Curso Maven 2
<option>one</option>
<option>two</option>
<option>three</option>
</options>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
Como podemos observar os elementos na configuração coincidem com os nomes dos
campos no Mojo. O mecanismo de configuração que o Maven emprega é muito semelhante
à maneira como XStream trabalha onde os elementos em XML são mapeados para os
objetos. Assim, a partir do exemplo acima, podemos ver que o mapeamento é muito para a
frente os mapas do elemento URL para o campo url, os mapas de elementos de tempo limite
para o campo de tempo limite e os mapas opções de elementos para o campo de opções.
O mecanismo de mapeamento pode lidar com matrizes, inspecionando o tipo de campo e
determinar se um mapeamento adequado é possível. Para os Mojos que se destinam a ser
executados diretamente a partir da CLI, seus parâmetros geralmente fornecem um meio
para ser configurado através de propriedades do sistema em vez de uma seção
<configuration> no POM.
A documentação de plugin para esses parâmetros lista uma expressão que denota as
propriedades do sistema para a configuração. O parâmetro URL está associado com a
expressão ${query.url}, o que significa que seu valor pode ser especificado pela
propriedade query.url do sistema:
mvn myquery:query -Dquery.url=http://maven.apache.org
O nome da propriedade do sistema não corresponde necessariamente ao nome do
parâmetro Mojo. Embora esta seja uma prática bastante comum, muitas vezes devemos
notar que os plugins que utilizam algum prefixo para as propriedades do sistema evitam
conflitos de nome com outras propriedades do sistema. Embora raramente, também existem
parâmetros de plugin que (por exemplo, por razões históricas) empregar as propriedades do
sistema que são completamente alheios ao nome do parâmetro. Então não devemos
esquecer de ter um olhar mais atento sobre a documentação do plugin.
Meta help
Os mais recentes plugins do Maven possuem geralmente uma meta help para auxiliar uma
linha de comando na descrição do plugin, seus parâmetros e tipos. Por exemplo, para
entender o objetivo javadoc, chamamos:
mvn javadoc:help -Ddetail -Dgoal=javadoc
E como resposta veremos todos os parâmetros para a meta javadoc:javadoc,.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
26 de 41
Curso Maven 2
Parâmetros de Configuração
Mapeamento de Objetos Simples
Mapeamento de tipos simples, como um lógico ou um inteiro, é muito simples. O elemento
<configuration> pode ser semelhante a seguinte linha de código:
<configuration>
<myString>a string</myString>
<myBoolean>true</myBoolean>
<myInteger>10</myInteger>
<myDouble>1.0</myDouble>
<myFile>c:\temp</myFile>
<myURL>http://maven.apache.org</myURL>
</configuration>
Mapeamento de Objetos Complexos
Mapeamento de tipos complexos também podem ser utilizados pelo Maven, então vamos
verificar um simples exemplo, onde mapeamos uma configuração para o objeto Person. O
elemento <configuration/> pode ser semelhante a seguinte linha de código:
<configuration>
<person>
<firstName>Fernando</firstName>
<lastName>Anselmo</lastName>
</person>
</configuration>
As regras para o mapeamento de objetos complexos são os seguintes:
•
Deve haver um campo particular que corresponde ao nome do elemento que está
sendo mapeado. Assim, no nosso caso o elemento pessoa deve ser mapeado para
um campo de pessoa no mojo.
•
O objeto instanciado deve estar no mesmo pacote do Mojo. Portanto, se o mojo está
na com.mycompany.mojo.query então o mecanismo de mapeamento analisa o
pacote e procura um objeto chamado Person. Como podemos observar o mecanismo
capitaliza a primeira letra do nome do elemento e ao utilizar isso para buscar o objeto
para instanciar.
•
Se deseja que o objeto seja novamente instanciado em um pacote diferente ou ter um
nome mais complexo, então devemos especificar usando um atributo de execução
como o seguinte:
<configuration>
<person implementation="x25.com.mojo.query.SuperPerson">
<firstName>Fernando</firstName>
<lastName>Anselmo</lastName>
</person>
</configuration>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
27 de 41
Curso Maven 2
Mapeamento de Coleções
O mecanismo de mapeamento de configuração pode facilmente lidar com a maioria das
coleções, então vejamos alguns exemplos como isso pode ser realizado.
Listas de mapeamento
Funciona quase da mesma maneira como o mapeamento de matrizes onde uma lista de
elementos serão mapeados para a lista. Então, podemos ter o seguinte mojo:
public class MeuAnimalMojo extends AbstractMojo {
private List animais;
...
}
}
Onde temos uma coleção chamada animais, em seguida, essa seria a configuração para o
plug-in:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-meuanimal-plugin</artifactId>
<configuration>
<animais>
<animal>gato</animal>
<animal>cachorro</animal>
<animal>cobra</animal>
</animais>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
Onde cada um dos animais referidos seriam entradas na coleção animais. Diferentemente
de um array, uma coleção não possui nenhum tipo de componente específico. A fim de obter
o tipo de um item da lista, a estratégia a seguir é:
•
Se o elemento XML contém uma implementação do atributo hint, que é usado
•
Se a tag XML contém um “.”, tentamos isso como um nome de classe totalmente
qualificado
•
Tentar a tag XML (com a primeira letra maiúscula) como uma classe no mesmo
pacote que o mojo/objeto que está sendo configurado
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
28 de 41
Curso Maven 2
•
Se o elemento não tem filhos, assume seu tipo String. Caso contrário, a configuração
falha.
Mapas de mapeamento
De maneira semelhante, é possível definir mapas (java.util.Map) como o seguinte:
private Map meuMapa;
E então:
<configuration>
<meuMapa>
<key1>valor1</key1>
<key2>valor2</key2>
</meuMapa>
</configuration>
As propriedades podem ser definidas da seguinte maneira:
private Properties minhasPropriedades;
E então:
<configuration>
<minhasPropriedades>
<property>
<name>propriedadeNome1</name>
<value>propriedadeValor1</value>
<property>
<property>
<name>propriedadeNome2</name>
<value>propriedadeValor2</value>
<property>
</minhasPropriedades>
</configuration>
Configurando os Plugins de Construção
A seguir, veremos como configurar os Plugins de Construção no elemento <build>.
Usando a tag <executions>
Também podemos configurar um mojo usando a tag <executions>. Esta é maneira mais
comumente utilizada para os mojos que se destinam a participar em algumas fases do ciclo
de vida. Usando MyQueryMojo como um exemplo, podemos ter algo parecido com:
<project>
...
<build>
<plugins>
<plugin>
<executions>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
29 de 41
Curso Maven 2
<execution>
<id>execucao1</id>
<phase>test</phase>
<configuration>
<url>http://www.foo.com/query</url>
<options>
<option>um</option>
<option>dois</option>
<option>tres</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
<execution>
<id>execucao2</id>
<configuration>
<url>http://www.bar.com/query</url>
<options>
<option>quatro</option>
<option>cinco</option>
<option>seis</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
A primeira execução com id "execucao1" liga esta configuração com a fase “test”. A
segunda execução não possui uma tag <phase>, desta forma, as metas podem ter uma
fase de ligação padrão. Se o objetivo tem uma ligação de fase “default”, então executa essa
fase. Mas se o objetivo não está vinculado a qualquer fase do ciclo de vida, então
simplesmente não será executado durante o ciclo de vida “compile”.
Observe que, embora a execução do id tem que ser único entre todas as execuções de um
plugin dentro de um POM, não necessitam ser único em toda uma hierarquia de herança de
POMs. Execuções com o mesmo id em POMs diferentes são mesclados. O mesmo se
aplica às execuções que são definidas por perfis.
E se possuímos múltiplas execuções com diferentes fases ligadas a elas? Vamos usar o
exemplo anterior do POM, só que desta vez vamos ligar “execucao2” a uma fase.
<project>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
30 de 41
Curso Maven 2
...
<build>
<plugins>
<plugin>
...
<executions>
<execution>
<id>execucao1</id>
<phase>test</phase>
...
</execution>
<execution>
<id>execucao2</id>
<phase>install</phase>
<configuration>
<options>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Se há várias execuções ligadas a diferentes fases, em seguida, o mojo é executado uma vez
para cada fase indicada. Significado, execucao1 será executado aplicando a definição da
configuração, quando a fase da construção for a de “test”, e execucao2 será executado
aplicando a configuração quando a fase “build” já está em instalação.
Agora, vamos ter um outro exemplo de mojo que mostra um padrão de ligação da fase do
ciclo de vida.
public class MyBindedQueryMojo extends AbstractMojo {
private String url; // expression="${query.url}"
private int timeout; // default-value="60"
private String[] options;
...
}
}
A partir deste exemplo, MyBindedQueryMojo é, por padrão ligado à fase “package”. Mas, se
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
31 de 41
Curso Maven 2
desejamos executar esse mojo durante a fase “install” e não “package” podemos religar
esse mojo em uma nova fase do ciclo de vida usando a tag <phase> e <execution>.
<project>
...
<build>
<plugins>
<plugin>
<executions>
<execution>
<id>execucao1</id>
<phase>install</phase>
<configuration>
<options>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Agora, MyBindedQueryMojo é a fase padrão que é pacote sobrescreveu a fase de
instalação. As configurações internas a tag <executions> diferem das configurações
externas no qual não podem ser utilizadas em uma chamada direta na linha de comando.
Em vez disso, só são aplicadas quando são obrigadas na fase do ciclo de vida.
Alternativamente, ao modificar uma seção da configuração fora da seção de execuções,
será aplicado globalmente para todas as invocações do plugin.
Usando a tag <dependencies>
Podemos configurar as dependências dos plugins de compilação, comumente usando uma
versão mais recente dependência. Por exemplo, o Plugin Antrun versão 1.2 usa o Ant
versão 1.6.5, se desejamos usar uma versão mais recente do Ant na execução deste plugin,
precisamos adicionar o elemento <dependencies>, conforme a seguinte codificação:
<project>
...
<build>
<plugins>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
32 de 41
Curso Maven 2
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
...
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
</project>
Usando a tag <inherited>
Por padrão, a configuração do plug-in deve ser propagada para os POMs filhos, para
interromper a herança, podemos usar a tag <inherited>, conforme a seguinte codificação:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<inherited>false</inherited>
...
</plugin>
</plugins>
</build>
...
</project>
Configurando os Plugins de Relatório
Para configurarmos os plugins de relatório usamos o elemento <reporting>. Configurar um
plugin de relatório no elemento <reporting> ou <build>, pois o POM NÃO realiza o mesmo
comportamento.
mvn site
São usados apenas os parâmetros definidos no elemento <configuration> de cada Plugin
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
33 de 41
Curso Maven 2
de Relatório especificado no elemento <reporting>, ou seja, sempre ignora os parâmetros
definidos no elemento <configuration> de cada plugin especificado no <build>.
mvn aplugin:areportgoal
Usamos os parâmetros definidos no elemento <configuration> de cada Plugin Relatório
especificado no elemento <reporting>; se um parâmetro não for encontrado, procura por um
parâmetro definido no elemento <configuration> de cada plugin especificado no <build>.
Usando a tag <reportSets>
É possível configurar um Plugin de Relatório utilizando a tag <reportSets>. Esta é mais
comumente usada para gerar relatórios seletivamente ao executar o comando mvn site.
Para gerar apenas o relatório da equipe do projeto, usamos a seguinte codificação:
<project>
...
<reporting>
<plugins>
<plugin>
<artifactId>maven-project-info-reports-plugin</artifactId>
<reportSets>
<reportSet>
<reports>
<report>project-team</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
...
</project>
Para eliminar todos os relatórios, precisamos usar:
<reportSets>
<reportSet>
<reports/>
</reportSet>
</reportSets>
Usando a tag <inherited>
Similar aos Plugins de Construção, para interromper a herança, podemos utilizar a tag
<inherited>:
<project>
...
<reporting>
<plugins>
<plugin>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
34 de 41
Curso Maven 2
<artifactId>maven-project-info-reports-plugin</artifactId>
<inherited>false</inherited>
</plugin>
</plugins>
</reporting>
...
</project>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
35 de 41
Curso Maven 2
9. Profiles
Maven 2.0 é utilizado para grandes projetos e visa garantir que as compilações sejam
portáveis Entre outros detalhes, isso significa permitir uma configuração de compilação
dentro do POM, evitando que todas as referências do sistema de arquivos (herança,
dependências e outros locais), e voltado fortemente para o repositório local de modo a
armazenar os metadados necessários para tornar isso possível.
No entanto, às vezes a portabilidade não é inteiramente possível. Sob certas condições, os
plugins precisam ser configurados com os caminhos do sistema de arquivos locais. Por outro
lado, um conjunto de dependência ligeiramente diferente será necessária, e o nome do
projeto pode ter de ser ajustado manualmente. Em outras ocasiões, pode ser necessário
incluir um plugin para todo o ciclo de vida, dependendo do ambiente de construção
detectado.
Para responder a estas necessidades, o Maven 2.0 introduz o conceito de um profile (perfil)
de construção. Os profiles são especificados em um subconjunto de elementos disponíveis
no POM, e são disparados em uma variedade de maneiras. Modificar o POM em tempo de
compilação, são utilizados conjuntos complementares de parâmetros “equivalentes mas
diferentes” para um conjunto de ambientes destino (fornecendo, por exemplo, o caminho da
raiz aplicativo servidor no desenvolvimento de testes, e ambientes de produção). Como tal,
os profiles podem facilmente levar a resultados diferentes se construído por diferentes
membros de sua equipe. No entanto, se usados corretamente, os perfis podem ser usados
ao mesmo tempo preservando a portabilidade do projeto. Isto também minimiza o uso da
opção -f do Maven que permite ao utilizador para criar uma outra POM com diferentes
parâmetros de configuração ou para construir o que torna mais fácil de manter uma vez que
é executado em um único POM.
Diferentes tipos de profile
Existe diferentes formas para definir um profile que varia:
•
Por Projeto: no próprio POM (pom.xml)
•
Por Usuário: nas configurações do Maven (%USER_HOME%/.m2/settings.xml)
•
Global: nas configurações globais do Maven (%M2_HOME%/conf/settings.xml)
•
Profile descriptor: um descritor localizado no projeto basedir (profiles.xml)
Acionando profiles
Um profile pode ser acionado/ativado de várias maneiras:
•
Explicitamente
•
Através das configurações do Maven
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
36 de 41
Curso Maven 2
•
Com base em variáveis de ambiente
•
Configurações do Sistema Operacional
•
Arquivos presentes ou ausentes
Detalhes sobre a ativação de profiles
Os profiles podem ser explicitamente especificados usando a opção -P CLI. Esta opção tem
um argumento que é uma lista de profiles delimitada por vírgulas. Quando esta opção for
especificada, os profiles diferentes dos especificados no argumento será ativado.
mvn groupId:artifactId:goal -P perfil-1,perfil-2
Os profiles podem ser ativados nas configurações do Maven, através da seção
<activeProfiles>. Vejamos uma lista de elementos <activeProfile>, cada um contendo um
profile-ID.
<settings>
...
<activeProfiles>
<activeProfile>perfil-1</activeProfile>
</activeProfiles>
...
</settings>
Os profiles listados na tag <activeProfiles> seriam ativados por padrão cada vez que um
projeto for usá-lo. Os profiles podem ser acionados automaticamente com base no estado
detectado do ambiente de compilação. Estas ativações são especificadas através na seção
<activation> no próprio elemento <profile>. Atualmente, esta detecção é limitada a prefixo
de correspondência da versão do JDK, a presença de uma propriedade do sistema ou o
valor de uma propriedade do sistema. Vejamos o seguinte exemplo:
<profiles>
<profile>
<activation>
<jdk>1.4</jdk>
</activation>
...
</profile>
</profiles>
Intervalos também podem ser usados como no Maven 2.1. Para as seguintes versões 1.3,
1.4 e 1.5.
<profiles>
<profile>
<activation>
<jdk>[1.3,1.6)</jdk>
</activation>
...
</profile>
</profiles>
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
37 de 41
Curso Maven 2
Usar um limite superior, tal como, 1.5] não incluirá as modificações realizadas na versão 1.5,
pois possuem "patch" de liberação adicional, como por exemplo _05, que não é levado em
consideração na faixa. Este próximo exemplo ativa o profile com base nas configurações do
sistema operacional.
<profiles>
<profile>
<activation>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
</os>
</activation>
...
</profile>
</profiles>
O seguinte profile é ativado quando o sistema de propriedade "debug" for especificado com
qualquer valor:
<profiles>
<profile>
<activation>
<property>
<name>debug</name>
</property>
</activation>
...
</profile>
</profiles>
O próximo exemplo irá acionar o profile quando o sistema de propriedade "environment"
(ambiente) for especificado com o valor "test" (teste):
<profiles>
<profile>
<activation>
<property>
<name>environment</name>
<value>test</value>
</property>
</activation>
...
</profile>
</profiles>
Para ativar este profile devemos digitar a seguinte linha de comando:
mvn groupId:artifactId:goal -Denvironment=test
Os profiles do Maven permitem uma parametrização do processo de construção com a
finalidade de permitir que a aplicação destino seja portátil para os diversos ambientes de
implantação.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
38 de 41
Curso Maven 2
10. Erros comuns
A "Síndrome Frustração Maven" é algo que muitos desenvolvedores já sofreram. Felizmente,
existem maneiras de colocar o Maven no caminho correto. Esta é uma lista de erros
ocorridos em muitos projetos e o que fazer com eles. A melhor parte de tudo isso é que
existem soluções rápidas para a maioria dos problemas.
Atualizar constantemente e usar o "install mvn"
Este é um problema muito comum. E sua correção trará benefícios para muitos dos pontos
abaixo. Aqui está uma declaração que pode ser encontrada em qualquer lugar na
documentação do Maven, devemos observar a seguinte máxima: "Todo artefato Maven tem
que ter uma pasta em um repositório do Maven". Isso significa que, na empresa, devemos
ter um repositório gerente, como “Arquivo” ou “Artefato”. Cada módulo desenvolvido deve
ser implantado para este repositório. Quando devemos implementar nossos artefatos? Após
cada execução bem-sucedida do servidor de compilação. Quando cada módulo for
implantado, a instalação do Maven buscará as dependências neste repositório, ou seja,
evitamos "para atualizar devemos instalar tudo". Ao trabalhar em um módulo, só devemos
construir o módulo. E os outros módulos serão transferidos automaticamente.
Resolver o erro "dependência não encontrado" copiando inteiramente a pasta m2
através do Memory Stick
Tão louco como essa solução se parece de maneira semelhante, a solução é ter um
repositório gerente. Uma vez que este está ligado corretamente, não teremos que repetir a
pergunta "Quem tem um cartão de memória?". Não devemos ter medo de limpar o
repositório local completamente, já que a velocidade de download do gerenciador de
repositório local é muito rápida.
Resolver problemas de dependências, como a falta das versões antigas dos artefatos,
obtendo um arquivo mais recente, mudando a versão no POM e depois instalar esse
módulo
Considere um cenário no qual foi modificado a versão de um módulo de 1.3 para 1.4. Só que
nunca mais foi utilizado este projeto que continua na versão 1.3. Só que agora existe um
outro módulo que depende da 1.3. É possível procurar no histórico a última modificação do
módulo, onde a versão ainda era a 1.3 e reatualizar para essa versão e reinstalá-la. Ou
podemos fazer uma modificação no último check-out 1.4 – 1.3, instalar e depois cruzar os
dedos e esperar que tudo funcione. Concordem que isso não é uma boa solução. Mais uma
vez, se a empresa possui um repositório gerente, e se houvesse ao menos uma construção
bem sucedida, então a versão 1.3 estaria nesse repositório.
Possuir arquivos do tipo Shell Scripts que percorrem as pastas de destino de seus
módulos para criar um arquivo zip
O Maven possui uma maneira de realizar essa tarefa, chamado de "conjuntos". Não é o
método mais fácil de configurar, mas após configurá-lo, irá se integrar com o Maven em uma
maneira muito mais suave do que a maioria das soluções “caseiras” de scripts. Existem
várias coisas que podem dar errado com esses scripts, uma vez que as versões começam a
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
39 de 41
Curso Maven 2
mudar, os módulos são movidos e assim por diante. Isso é uma questão de utilizar a
ferramenta correta para fazer o trabalho. Isto também significa que é possível criar um
montador e implantá-lo no repositório do Maven.
Possuir muitos arquivos XML em seus POMs cuja única finalidade é copiar os
arquivos em suas pastas
Maven não foi construído para simplesmente copiar arquivos. Se tudo que deseja fazer é
copiar um artefato (um arquivo WAR, EAR ou ZIP), pode ser muito mais fácil criar um script
no ANT para realizar esse trabalho.
A compilação é constantemente interrompida e mostrada a mensagem "verificação de
atualizações de xxx-repo" e não existe motivo
Este é um problema que poucos desenvolvedores conseguem encontrar a causa raiz. Talvez
a demora é uma boa desculpa para ir buscar um café. De qualquer forma, uma causa
comum deste problema é a existência de muitas dependências e um considerável número
de repositórios listados em seus arquivos POM. Maven não tem noção de que o artefato
deve verificar em qual repositório, por isso felizmente olha para atualizações de todos os
artefatos e em todos os repositórios. Mais uma vez o truque é usar um repositório
gerenciador. Ao configurar a instalação do Maven para procurar os artefatos neste
repositório (através da criação de um espelho na sua settings.xml), Maven verificaria
unicamente neste local. Então, uma vez que este servidor é local, tudo será realizado
rapidamente. É importante aqui que o repositório gerente seja configurado corretamente.
Ao trabalhar em um ramo, a construção de outro ramo pode falhar (ou seja, as
bibliotecas devem ser boas suficiente para todos)
Existem algumas coisas que devemos lembrar de fazer ao criar um “ramo” do seu projeto.
Informar ao servidor de compilação para construir este ramo e mudar a versão em seus
arquivos POM. Ao negligenciar este último, os problemas surgirão ao alterar uma assinatura
de um método em seu ramo, e tentar desenvolver novamente. Existe uma meta no plugin
release chamada "branch", então através do comando "mvn release:branch", o Maven
renomeará automaticamente as versões nos POMs.
Toda empresa possui uma dependências interna com o final -SNAPSHOT
A ideia de um snapshot pode parecer reconfortante para os desenvolvedores. Está quase
pronto, porém cedo ou tarde, teremos que liberar o módulo. Existem alguns problemas como
ficar com um snapshot eternamente. Primeiro, a diminuição de sua construção, pois o
Maven deve verificar o último snapshot dos repositórios remotos. Segundo, ao depender de
um snapshot, fica difícil reconhecer qual versão se está dependendo. Ao depender de um
módulo interno da empresa que funciona do jeito que está agora, pode ser uma boa ideia
soltar um novo release desse módulo e alterar a dependência da versão sem snapshot.
Ao o comando "mvn dependency:analyze" a lista de dependências não utilizadas e
não declaradas pode ser longa demais para ser realizada
Isto pode parecer banal, mas existe um perigo real de não conhecermos exatamente do que
dependemos. O maior problema é causado pela maneira de lidar com as dependências
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
40 de 41
Curso Maven 2
transitivas. Devido a isso, podemos usar o código em seu dependency as dependências e o
Maven compilará muito bem. Os problemas surgem ao decidir uma alteração do escopo do
qual existe uma dependência do "provided", ou os módulos que dependem e decidem mudar
suas dependências.
Ao liberar a release de uma nova versão de um plugin, as construções tendem a falhar
O Maven por alguma razão decidiu que não é necessário especificar a versão do seu plugin
dependencies. O Maven localiza a mais recente versão quando uma nova versão de um
plugin for liberada. Às vezes, "mais recente" não é tão boa assim, pois novas versões podem
conter novos bugs. Portanto, é uma boa prática declarar a versão que desejamos usar ao
especifica um plugin no seu POM. Se realmente quiser ter certeza, também podemos
especificar as versões dos plugins internos do Maven.
C E P : 7 0 . 3 9 0 - 1 0 0 – Fo n e / Fa x : ( 6 1 ) 3 2 4 4 - 2 5 1 0 – 3 2 4 2 - 4 3 3 9
41 de 41

Maven 2 - Clicks de Fernando Anselmo

Transcrição

Documentos relacionados

Procedimento para Instalação do Plugin do Flash

Baixe meu currículo aqui

Como Instalar Plugins no Eclipse?

Cofrinho Missionário

full stack web developer

Edi Carlos Siniciato

Baixar - Unipar

Edital 20-2014 - Pensando o Direito

Integração com o Wordpress v0.1

Apresentação do PowerPoint - Pontifícias Obras Missionárias