Curso Maven POM Parte 3

Maven - Curso Básico
Aula 04 - POM - Parte 3

Agenda
● Aula 1: Introdução;
● Aula 2: O POM - Parte 1;
● Aula 5: Ciclos de Vida;
● Aula 6: Build Profiles;
● Aula 7: Plugins, CLI e Conclusão;
2Édipo Daniel Aragão - Maven Básico

Frase Motivacional
3
“A melhor maneira de prever o futuro é inventá-lo.” - Tiozão do Bar
Édipo Daniel Aragão - Maven Básico

Alan Kay
4
1. Um dos criadores do Small Talk;
2. Um dos pais da Orientação a Objetos;
3. Pioneiro em propostas de UI;
4. Concebeu o primeiro Laptop;
5. Guitarrista de Jazz!

Project Object Model (POM)
O POM é onde um projeto:
1. Tem sua identidade definida;
2. Tem sua estrutura declarada;
3. Tem o build é configurado;
4. É relacionado a outros;
5. Define suas dependências.
O POM define um projeto Maven! É o mapa do projeto!
O POM é declarativo! Descritivo!

Última Aula
1. Versões (Meu Projeto)
2. Properties
3. Dependências, escopo (5 tipos):
1. Compile
2. Provided
3. Runtime
4. Test
5. System
Mais um pouco sobre dependências...

Dependências Opcionais
7
1. A seguir temos um exemplo de um projeto que usa uma dependência
opcional, no caso ele delegará a escolha dessa dependência para um outro
projeto que o use.

9
1. Quando minha-aplicacao inclui o meu-projeto, ele precisa definir qual das
dependências opcionais irá usar. Neste caso seria uma aplicação que poderia
fazer um cache em memória usando ehcache, ou em disco usando
swarmcache.

Dependências - Versões
11
1. Comumente define-se a versão de uma dependência da seguinte forma:
a. Porém existe um risco, o Maven ainda pode buscar uma versão mais
nova…?

Dependências - Ranges de Versão
12
1. Podemos especificar ranges para as versões de uma dependência!
2. Não precisamos "amarrar" nossas versões;
3. Temos 2 quantificadores:
a. (, ) → exclusivos;
b. [, ] → inclusivos.

Dependências - Ranges de Versão
13
1. 4. [,3.8.1] → Todas dependências não maiores que 3.8.1 ( x <= 3.8.1 )
2. 5. [4.0,) → Todas versões maiores ou igual a 4.0 ( x >= 4.0 )
3. 6. (,2.0) → Qualquer versão menor que 2.0 ( x < 2.0 )
4. 7. [1.2] → Somente a versão 1.2! ( x == 1.2 )
5. 8. [1.2,1.3] → Todas de 1.2 e 1.3 inclusive. ( 1.2 <= x <= 1.3 )
6. 9. [1.2,1.3) → Todas de 1.2 inclusive até 1.3. ( 1.2 <= x < 1.3 )

Versões - Exercício 2
14
1. Vamos testar os conceitos com o projeto “Exercicio 2 - Versoes”;
2. Tente construir o “projeto-1”;
3. Faça uma análise do processo de construção.
a. Qual dependência é incluída no processo de compilação?
b. Como você chegou a essa conclusão?
c. Troque a versão do Projeto 3 e 4, inclua [ ], o que acontece? Exemplo:
i. [1.2.0b]
ii. [1.0.1b]

Dependências Transitivas
15
1. Um projeto A dependem de um projeto B que depende de um projeto C.
2. O projeto C é considerada uma dependência transitiva de A.
3. Se o projeto C depende do projeto D, o projeto D é também uma
dependência transitiva de A.
4. O Maven (a partir da versão 2) faz a gestão dependências transitivas.
5. O Maven lida com os conflitos:
a. Se dois projeto tem dependências com mesmo groupid e artifactid:
i. Favorece a mais recente.
6. Isso pode causar problemas, e deveremos usar exclusões.

Dependências Transitivas e Escopo
16
1. Cada um dos escopos apresentados afeta não somente a disponibilidade da
dependência, mas também sua transitividade.
2. Os escopos no topo da coluna representa o escopo da dependência transitiva.
3. Os escopos na coluna mais à esquerda representa o escopo da dependência direta.
4. A intersecção de linha e coluna é o escopo definido para a dependência transitiva.
5. Uma célula em branco indica que a dependência será omitida.

Dependências Transitivas e Escopo
17
1. Exemplo:
a. O Projeto A tem como dependência o Projeto B com scope test.
b. O Projeto B tem como dependência o Projeto C com scope compile.
c. O Projeto C é uma dependência transitiva em A, e terá o scope test.
d. https://maven.apache.org/guides/introduction/introduction-to-dependency
-mechanism.html

Resolução de Conflitos
18
1. Haverá momentos em que será preciso excluir dependências transitivas;
2. Quando existe uma dependência que não será utilizada;
3. Quando desejo substituir uma dependência por outra mais conveniente.

Excluindo ou Adicionando
19
1. No exemplo acima não queremos a dependências JTA (não está disponível no Maven
Repository). Esta dependência não é aberta, mas faz parte do Hibernate;
2. Substituímos por uma versão alternativa:

Motivos para Excluir e Adicionar
uma Dependência
20
1. Mudança de groupId e artifactId de uma dependência:
a. Acaba gerando duas cópias no projeto;
2. Um artefato não é utilizado no projeto, e você quer reduzir o número de
bibliotecas distribuídas com sua aplicação.
3. Um artefato que é provided e não deveria ser incluso no seu build;
4. Excluir dependências de APIs com múltiplas implementações (Ex. SLF4J);

dependencyManagement
21
1. Gestão de dependências pode virar um cenário bastante complexo;
2. Existe o dependencyManagement:
a. É um elemento em geral adicionado a um POM pai.
b. Neste elemento você afeta os filhos sem editar seus POMs.
c. Maven irá seguir a hierarquia pai-filho e usará a versão definida no
dependencyManagement.

23
1. POM Pai:

24
1. POM Filho:

25
1. Perceba que o projeto filho não especifica uma versão da dependência;
2. A versão foi definida no pai (no dependencyManagement) e propagada para o
projeto filho;
3. Se o filho definir uma versão ela irá sobrescrever a definição do pai;
4. Se não, usará a do pai (dependencyManagement);
5. Ao contrário da declaração de uma dependência normal:
a. Uma dependência em dependencyManagement não será propagada a
todos os projetos filhos;
b. Somente utilizada para gerenciar a versão.
6. Permite declarar dependências sem definir versões.

Relações de um Projeto

1. Uma das motivações para o uso do Maven é que ele faz o tracking de
dependências (e dependências de dependências) facilmente;
2. Como vimos anteriormente, quando um projeto depende de um artefato
produzido por outro, dizemos que esse outro artefato é uma dependência;
3. Podemos ter dependências externas como um JUnit por exemplo ou mesmo
de outro projeto;

1. Relações não são somente sobre dependências:
2. Ainda temos Herança (projeto pai) e Agregação (sub-módulos).
3. Se Projeto A tem relação com o Projeto B, Maven é esperto suficiente para
construir B antes de A;

Coordenadas
1. Projetos são relacionados um com outro através de coordenadas (+ | -).
2. Projetos são identificados por:
a. groupId;
b. artifactId;
c. version.
3. A definição dessa tríade é mandatória!

groupId
1. Agrupa um conjunto de artefatos relacionados;
2. Sua definição é similar a de um package;
3. Será convertido numa estrutura de pastas:
a. Ex. br.com.edipoaragao → ~/.m2/repository/br/com/edipoaragao/

artifactId
1. É o principal identificador de um projeto;
2. É o nome deste artefato;
3. Para utilizar este projeto você precisa referenciar este artefactId;
4. Combinação groupId e artifactId precisa ser única.

version
1. Quando um artefato é gerado ele tem um número de versão;
2. Vimos anteriormente as regras para definir uma versão.

type
1. Será visto com maior detalhes na sessão de ciclo de vida;
2. É o formato do empacotamento do Maven;
a. ear
b. jar (default)
c. war
d. pom
i. geralmente utilizado para criar herança
ii. pode ser usado para agrupamento de dependências
e. maven-archetype
f. maven-plugin

Notação de Coordenadas
1. Simplificada:
a. groupId:artifactId:version.
2. Completa
a. groupId:artifactId:classifier:version

Herança
1. Permite que um projeto herde informações de um POM pai;
2. Evita repetição de declarações comuns:
a. Similar a herança do Java.

Herança

Herança
1. Quando um projeto especifica um projeto pai, este projeto pai passa a ser o
ponto de início de leitura do Maven;
2. O projeto herda praticamente tudo, incluindo o artifactId ou groupId e o
version;
3. Se o Projeto B não prover essas informações (sobrescrita seletiva), serão
utilizadas a do pai.

O que é Herdado?
1. Identificadores (ao menos o groupId ou artifactId devem ser sobrescritos);
2. Dependências;
3. Desenvolvedores e Contribuidores;
4. Lista de Plugins;
5. Lista de Reports;
6. Execução de Plugin (execuções com mesmos ids são mergeadas);
7. Configuração de Plugin.

Dependências no Parent POM
1. Quando Maven herda dependências, ele irá adicionar as dependências do
projeto pai ao projeto filho;
1. Isso é interessante para propagar dependências entre vários projeto;
2. Por exemplo, dependência de logging (todos projetos devem usar LogBack).
3. Ou o mesmo plugin para todos os projetos.

Parent POM não Default
1. IMPORTANTE:
a. O Maven irá assumir que o parent POM estará disponível no repositório local, ou
disponibilizado no diretório pai: ../pom.xml do projeto atual;
b. Se nenhuma das situações for verdadeira, por quaisquer motivos, você pode contornar o
problemas, especificando o path do parent pom:

Agregação
1. Num projeto multi-módulo (com agregação) você está simplesmente dizendo
ao projeto que sua construção deve incluir outros módulos específicos.

Agregação vs. Herança
1. Agregação somente define um build dentro de outro;
2. Herança lida com os aspecto de definições de um projeto, um POM deriva de
outro;
3. Como decidir entre eles?

Agregação vs. Herança

Referências Adicionais
45
1. http://kevinboone.net/classpath.html
2. https://docs.oracle.com/javase/tutorial/essential/environment/paths.html
3. https://maven.apache.org/guides/introduction/introduction-to-dependency-me
chanism.html

Curso Maven POM Parte 3

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Curso Maven POM Parte 3

Semelhante a Curso Maven POM Parte 3 (20)

Curso Maven POM Parte 3