Documente Academic
Documente Profesional
Documente Cultură
Versão 1.0
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
2 de 41
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
Curso Maven 2
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
3 de 41
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
Curso Maven 2
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.
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
4 de 41
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
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>
Mínimo POM
O requisito mínimo para um POM são os seguintes:
• modelVersion - deve ser definido para 4.0.0
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
5 de 41
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
Curso Maven 2
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.
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
6 de 41
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
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.
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 (e-
mails e arquivos) com todo o esboço dos programas e as configurações para a construção
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
7 de 41
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
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.
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
8 de 41
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
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/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
src/ Arquivos
main fontes da
/jav Aplicação /
a Biblioteca
src/ Recursos
main Aplicação /
/res Biblioteca
ourc
es
src/ Arquivos
main de recursos
/fil de filtro
ters
src/ Descritores
main de
/ass montagem
embl
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
9 de 41
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
Curso Maven 2
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
10 de 41
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
Curso Maven 2
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
11 de 41
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
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
Este comando percorre todos os subprojetos e executa uma limpeza, em seguida, instala
incluindo todas as etapas anteriores.
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
12 de 41
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
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
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
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
13 de 41
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
Curso Maven 2
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
14 de 41
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
Curso Maven 2
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
15 de 41
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
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.
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
16 de 41
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
Curso Maven 2
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 Z
como uma dependência opcional, usando o elemento "optional". Quando o projeto X
depende do projeto Y, X dependerá apenas Y, e não da dependência opcional do projeto Y
em Z. O dono do projeto X pode então adicionar explicitamente uma dependência para o
projeto Z.
Â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
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
17 de 41
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
Curso Maven 2
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
18 de 41
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
Curso Maven 2
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
19 de 41
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
Curso Maven 2
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
Escopo
compile U!O U!O U!O U!O
test ! U ! !
runtime ! U!O U!O U!O
provided U!O ! ! !
Legenda:
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 />.
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
20 de 41
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
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 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>
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
21 de 41
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
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>
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
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
22 de 41
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
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
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
23 de 41
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
Curso Maven 2
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
24 de 41
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
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 {
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>
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
25 de 41
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
Curso Maven 2
<option>one</option>
<option>two</option>
<option>three</option>
</options>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
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
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
26 de 41
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
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>
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
27 de 41
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
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 {
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>
<version>1.0</version>
<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
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
28 de 41
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
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>
E então:
<configuration>
<minhasPropriedades>
<property>
<name>propriedadeNome1</name>
<value>propriedadeValor1</value>
<property>
<property>
<name>propriedadeNome2</name>
<value>propriedadeValor2</value>
<property>
</minhasPropriedades>
</configuration>
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
29 de 41
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
Curso Maven 2
<execution>
<id>execucao1</id>
<phase>test</phase>
<configuration>
<url>http://www.foo.com/query</url>
<timeout>10</timeout>
<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>
<timeout>15</timeout>
<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>
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
30 de 41
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
Curso Maven 2
...
<build>
<plugins>
<plugin>
...
<executions>
<execution>
<id>execucao1</id>
<phase>test</phase>
...
</execution>
<execution>
<id>execucao2</id>
<phase>install</phase>
<configuration>
<url>http://www.bar.com/query</url>
<timeout>15</timeout>
<options>
<option>quatro</option>
<option>cinco</option>
<option>seis</option>
</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 {
A partir deste exemplo, MyBindedQueryMojo é, por padrão ligado à fase “package”. Mas, se
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
31 de 41
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
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>
<artifactId>maven-myquery-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>execucao1</id>
<phase>install</phase>
<configuration>
<url>http://www.bar.com/query</url>
<timeout>15</timeout>
<options>
<option>quatro</option>
<option>cinco</option>
<option>seis</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
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
32 de 41
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
Curso Maven 2
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
...
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
<version>1.7.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
</project>
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
33 de 41
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
Curso Maven 2
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
34 de 41
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
Curso Maven 2
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.1.2</version>
<inherited>false</inherited>
</plugin>
</plugins>
</reporting>
...
</project>
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
35 de 41
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
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.
Acionando profiles
Um profile pode ser acionado/ativado de várias maneiras:
• Explicitamente
• Através das configurações do Maven
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
36 de 41
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
Curso Maven 2
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>
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
37 de 41
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
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>
<version>5.1.2600</version>
</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>
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
38 de 41
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
Curso Maven 2
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
39 de 41
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
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
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
40 de 41
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
Curso Maven 2
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
41 de 41
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