Apresentação maven

Maven(básico)
S O F T P L A N , 1 6 D E A B R I L D E 2 0 1 4
SAJ-ADV
Apresentado por: André Justi

Maven é uma ferramenta de automação de projetos. É responsável por gerenciar
dependências, controlar versão de artefatos, gerar relatórios, garantir execução de
testes, manter nível de qualidade do código, dentre outras. Normalmente é usado em
projetos Java, mas também pode ser utilizado com as linguagens C#, Ruby, Scala e
outras. Maven atualmente está na versão 3.0.5 e é mantido pela Apache.
O Maven é construído em Java e em uma arquitetura baseada em plugins, o que
permite que ele seja facilmente extensível e customizável.

Alguns motivos para utilizar Maven
●
Padrão da comunidade: além de ser Open Source, Maven é de longe a
ferramenta de build mais utilizada. Sendo assim, inúmeras ferramentas são
baseadas ou possuem integração com ele.
●
Automatização do Build: o Maven vai fazer o build de sua solução. Ele utiliza
muito o conceito de convenção sobre configuração. Logo, se você colocar seus
artefatos nas estruturas padrão do maven, será necessário configurar poucas
coisas ou nada.
●
Build Modular: os projetos são estruturados de forma modular no Maven,
quando é feito o build em um projeto pai, ele faz o build de cada filho, o que é
muito útil, visto que deixa de ser necessário recompilar inúmeros projetos.

●
Cascateamento: Outra grande feature do Maven é o cascateamento de
configurações. Graças a sua estrutura de hierarquias de configuração, a qual retira
a necessidade de duplicação de configurações em projetos filhos, visto que estes
herdam todas as suas configurações do pai.
●
Plugins: No Maven tudo são plugins – o próprio core do Maven é feito de plug-ins.
Esses plugin vão desde de plugins que fazem o *clean* do projeto, aos plugins
que geram o Javadoc e plugins que geram estatísticas da qualidade do projeto.
Além de existirem muitos plugins para o Maven, é possível criar plugins de forma
fácil e com fácil integração.

●
Gerencia de Dependências: Quem já não ouviu falar do *jar hell*? Quando
usamos muitos frameworks em Java através de vários projetos, gerenciar esses
artefatos e controlar as suas versões é um verdadeiro caos. O Maven provê a
gerencia de jar e outros artefatos. Esses artefatos não ficam em um controle de
versão. Não é mais necessário criar uma pasta *lib* e coloca os jars lá, pois os
artefatos ficam no repositório do Maven.
●
Consistência: como Maven provê um padrão, todas as parametrizações são feitas
através de um arquivo e tudo da mesma forma. Assim ganha-se a facilidade de
integração entre projetos e a fácil reutilização deles.

●
Contexto e Informações: com o Maven é possível ter de forma contextualizada as
informações úteis do projeto. Ele pode gerar um site contendo: lista de
desenvolvedores, links para o controle de versão, links para o sistema de build
contínuo, lista de dependências do projeto, resultado da execução dos testes,
Javadoc e etc.
●
Ciclo de Vida: diferente de algumas ferramentas de build e gerenciamento de
dependências, o Maven possui um ciclo de vida definido. Assim, na medida em
que algo vai acontecendo ele vai mudando de estados no ciclo de vida,
determinados plugins(goals) vão sendo executados. É possível parametrizar o que
se quer que aconteça e em que momento do ciclo de vida.

●
Foco na Qualidade: O Maven incentiva a criação de testes unitários. De forma que
quando se faz o build/instalação ele roda todos os testes unitários
automaticamente. Caso algum teste unitário falhe, ele aborda a instalação/build.
Essa é uma excelente política para forçar os testes e a qualidade de projeto.

Instalação e configuração
Guia: http://maven.apache.org/download.cgi

POM.xml (Project Object Model)
Arquivo principal do Maven. Ele é um arquivo XML que contém informações sobre os
detalhes do projeto e de configuração utilizadas pelo Maven para construir o projeto. Ele
contém os valores padrão necessários para a maioria dos projetos.
Exemplos:
${project.build.directory} - Caminho dos arquivos após o empacotamento
${project.build.outputDirectory} - Caminho dos compilados após o empacotamento
${project.name} - Nome do projeto
${project.version} - Versão do projeto
Podemos configurar no arquivo pom dependências, plugins ou metas que podem ser
executadas, bem como perfis de construção e assim por diante.

POM.xml (Project Object Model)
Exemplo do conteúdo de um arquivo pom.xml
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>br.com.caelum</groupId>
<artifactId>teste</artifactId>
<version>1.0</version>
</project>

Propriedades
Como citado anteriormente, Maven possui parâmetros (variáveis).
Propriedades personalizadas:
<project>

<properties>
<minha.propriedade>adv mensagem</minha.propriedade>
</properties>

</project>
O uso de propriedades ${minha.propriedade} (forma de utilização no pom.xml) resultará
em `adv mensagem`.

Propriedades
Maven possui uma série de propriedades default.
<project.name> - Nome do projeto
<project.version> - Versão do projeto
OBS: Também podemos sobre escrever as propriedades.
Podemos passar propriedades por linha de comando, assim podemos passar uma
propriedade necessária ou sobrescrever alguma já configurada.
-D<nome_propriedade>=<valor_propriedade>.
Exemplo: -Dnome01=valor01 -Dnome02=valor02

Ciclo de vida - Clean Lifecycle
Fase Descrição
pre-clean Executa processos necessários antes da limpeza real do projeto
clean Remover todos os arquivos gerados pela compilação anterior
post-clean Executa os processos necessários para finalizar a limpeza projeto

Ciclo de vida - Default Lifecycle
Fase Descrição
validate
Valida se o projeto está correto e todas as informações necessárias estão
disponível.
initialize
Inicia o estado de construção, por exemplo, definição das propriedades ou
criação de diretórios.
generate-sources Geração de qualquer código fonte para inclusão na compilação.
process-sources Processa o código fonte, por exemplo, para filtrar os valores.
generate-resources Gera os recursos para inclusão no pacote .
process-resources
Copia e processa os recursos para o diretório de destino, tornando o projeto
pronto para compilação.
compile Compila o código fonte do projeto.
process-classes
Pós-processamento dos arquivos gerados de compilação, por exemplo, para
fazer melhorias em bytecodes de classes Java.
generate-test-sources Gera qualquer código fonte de teste para inclusão na compilação.
process-test-sources Processa o código fonte de teste, por exemplo, para filtrar quaisquer valores.
generate-test-resources Cria os recursos para o teste.

Fase Descricao
generate-test-resources Cria os recursos para o teste.
process-test-resources Copia e processa os recursos para o diretório de destino de teste.
test-compile Compila o código fonte de teste no diretório de destino teste.
process-test-classes Pós-processamento dos arquivos gerados a partir de compilação de teste.
test
Executa os testes usando um Framework de testes unitários adequado.
Estes testes não devem exigir o código já empacotado.
prepare-package
Realiza quaisquer operações necessárias para preparar um pacote antes de
a embalagem real. Isso muitas vezes resulta em uma versão
descompactada.
package
Gera o código compilado e empacotá-lo em seu formato de distribuição,
como um JAR.

Fase Descricao
pre-integration-test
Executa as ações necessárias antes de testes de integração são executados.
Isto pode envolver coisas como configuração de ambiente.
integration-test
Processa e implanta o pacote se necessário em um ambiente onde os testes
de integração podem ser executados.
post-integration-test
Executa as ações necessárias após os testes de integração serem executados.
Isto refere-se inclusive à limpeza do ambiente.
verify
Executa todas as verificações para verificar se o pacote é válido e atende aos
critérios de qualidade.
install
Instala o pacote no repositório local, para o uso como uma dependência em
outros projetos no ambiente local.
deploy
Instala o pacote em um servidor de integração, lançamento, repositório
remoto para compartilhar com o artefato com outros desenvolvedores e
projetos.

Ciclo de vida - Site Lifecycle
Você pode invocar qualquer dessas fases na linha de comando, digitando:
mvn [fase]
Por exemplo, se você digitar mvn package o Maven, irá executar todas as fases
anteriores do ciclo até a fase package.
Fase Descrição
pre-site Executa processos necessários antes da geração do site do projeto
site Gera a documentação site do projeto
post-site
Executa os processos necessários para finalizar a geração local, e para se
preparar para implantação do site
site-deploy Implanta a documentação gerada para o servidor web especificado

Convenções - groupId e artifactId
A identificação do projeto consiste em três informações:
●
groupId: um identificador da empresa/grupo ao qual o projeto pertence.
Geralmente o nome do site da empresa/grupo ao contrário (como nos pacotes do
Java). Ex: br.com.softplan.*
●
artifactId: o nome do projeto. Ex: adv.api
●
version: a versão atual do projeto. Ex: 1.0.0.0

Essas informações são usadas em muitos lugares, como no controle de dependências,
que é a funcionalidade mais útil do Maven. Por exemplo, para dizer que o log4j-1.2.15
é uma dependência da aplicação, acrescentamos no pom as linhas:
<project>
...
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
</dependencies>
...
</project>

Quando necessário, o Maven vai baixar o jar do log4j 1.2.15, e todas as dependências
necessárias, e vai colocá-las no classpath da sua aplicação durante os builds, testes,
etc. Ou seja, não precisamos mais entrar no site do log4j, baixar um zip com vários jars
e ter que procurar quais jars devem ser colocados no classpath.
No Repositório de Bibliotecas do Maven você encontra os jars que você pode colocar
como dependência do seu projeto, e o bloco de xml que você deve copiar e colar
dentro da tag dependencies do pom para incluir essas bibliotecas.
OBS: todos os jars baixados pelo Maven são guardados na pasta repository dentro do
M2_HOME que é configurado quando o Maven foi instalado. Assim, se mais de um
projeto depende do mesmo jar, ele não é baixado novamente.

Convenções - Pastas
Então se, por algum motivo a estrutura criada pelo Maven não o atende, ou está
querendo migrar um projeto para o Maven que não segue essa estrutura, pode-se
configurar os diretórios do projeto acrescentando algumas linhas no pom:
<project>
...
<build>
<sourceDirectory>
${project.basedir}/src/java/main
</sourceDirectory>
<testSourceDirectory>
${project.basedir}/src/java/test
</testSourceDirectory>
<resources>
<resource>
<directory>
${project.basedir}/src/resources/main
</directory>
</resource>
</resources>
<testResources>
<testResource>
<directory>
${project.basedir}/src/resources/test
</directory>
</testResource>
</testResources>
</build>
...
</project>

Repositórios
Repositório Local: Lendo o arquivo pom.xml do projeto, o Maven tenta encontrar
localmente as dependências. Quando esta busca não encontra um determinado JAR, o
Maven tenta obter nos próximos repositórios (mais detalhes adiante) uma cópia para o
repositório local. Desta maneira, em uma próxima execução, o JAR será encontrado.
Em outras palavras, o repositório local deverá conter todos JARs, os quais o projeto faz
referência.

Repositórios
Para procurar em outros repositórios, existe uma configuração que especifica os
mesmos.
Existem pelo menos três formas de fazer esta configuração:
●
Configurar no diretório de instalação do Maven (M2_HOME) o arquivo
settings.xml
●
Configurar no diretório do repositório local do usuário (M2_REPO) também o
arquivo settings.xml
●
Ou por último, diretamente no pom.xml do projeto.
Existem 2 tipos de repositórios Maven: Interno e Externo.

Repositórios

Repositório Interno
É um repositório criado dentro da rede da empresa. Como temos na Web o Nexus e
na Softplan o Artifactory

Repositório Externo
Basicamente é um repositório Maven público na internet.
Obs: algumas vezes, é necessário adicionar mais repositórios para encontrar os JARs do seu projeto. Um
único repositório pode não conter todas as dependências necessárias.

Repositório - Configuração
Exemplo de configuração que pode ser adicionada no pom.xml ou settings.xml para
configuração do repositório.

<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>central</id>
<name>Maven Repository</name>
<url>http://repo1.maven.org/maven2</url>
</repository>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/2/</url>
</repository>
<repository>
<id>jboss</id>
<url>http://repository.jboss.org/nexus/content/groups/public-jboss/</url>
</repository>
</repositories>

Plugins
Como citado anteriormente, a maioria dos recursos do Maven é provido através de
plug-ins. Tais plugins podem ser executados automaticamente associados à uma fase
ou profiles.
Algumas das fases do ciclo já possuem plugins associadas à elas, e esses plugins são
executados assim que a fase é chamada para ser executada. Também é possível
associar plugins para rodar em qualquer fase do ciclo, conseguindo, assim, personalizar
o build do projeto facilmente. Por exemplo, para criar um jar com o código fonte do
projeto, e que esse jar seja gerado depois que o projeto foi empacotado, é só
acrescentar no pom:

Plugins
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>

Plugins
Assim, o plugin Source vai executar a goal jar na fase package do ciclo de vida. É como
se fosse chamado mvn source:jar quando o build passa pela fase de package. A fase
package já possui um plugin associado à ela: o jar:jar (supondo que é um projeto jar),
então o plugin source só será executado depois do jar:jar. Em geral, se for registrado
mais de um plugin para a mesma fase, eles serão executados na ordem em que eles
forem declarados. O jeito de configurar o plugin para colocá-lo dentro de uma fase do
ciclo geralmente está no site principal do plugin, na seção Usage.

Gerenciamento de dependências
Para gerenciar dependências em um projeto é preciso alterar o arquivo pom.xml, mais
especificamente criar ou alterar a tag dependency que fica dentro de dependencies:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Para cada dependência uma tag dependency será necessária, informando o groupId,
artifactId e version. Por isso a importância da convenção desses três parâmetros.
Também pode-se adicionar a tag scope que por padrão vem com o valor compile.

Gerenciamento de dependências – Escopos
●
compile: Este é o escopo padrão, usado se nenhum for especificado. Esse escopo
faz a dependência estar disponível em todos os caminhos de um projeto. Além
disso, essas dependências são propagadas para projetos dependentes.
●
provided: Esse escopo é válido em compilação, mas indica que se espera que a
JDK ou um recipiente irá fornecer a dependência em tempo de execução. Por
exemplo, ao construir uma aplicação web para o Java EE, deve-se definir a
dependência da API Servlet e APIs Java EE relacionados ao escopo provided
porque o contêiner fornece essas classes. Este escopo está disponível apenas para
a compilação e teste de classpath, e não é transitivo.
●
runtime: Isto indica que a dependência não é necessária para a compilação, mas é
para ser execução.

Gerenciamento de dependências – Escopos
●
test: Esse escopo indica que a dependência não é necessária para o uso normal da
aplicaçãoe está disponível apenas para a compilação de teste e fases de execução
de teste.
●
system: Este escopo é semelhante ao provided, exceto pelo fato de que a
aplicação é responsável por informar o JAR que contém explicitamente.
●
import: Este escopo é utilizado apenas em uma dependência do tipo pom e na
seção <dependencyManagement>. Ela indica que o POM especificado deve ser
substituído com as dependências da seção <dependencyManagement> desse
POM. Uma vez que as dependências são importadas elas não serão transitivas.

Gerenciamento de dependências – Exclusões
Caso estejamos importando transitivamente uma dependência, podemos excluí-la.
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependencies>

Gerenciamento de dependências – Herança
Maven implementa um mecanismo de herança. Isso quer dizer que um dado POM
herda as configurações de seus ancestrais podendo sobrescrevê-las. Existe um POM
que é o ancestral de todos os POMs, o chamado super POM, de onde se herdam as
configurações padrões.
Para herdarmos um POM utilizamos:
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>br.com.adv</groupId>
<artifactId>projeto.pai</artifactId>
<version>1.0.0.0-SNAPSHOT</version>
</parent>
<artifactId>projeto.filho</artifactId>

Gerenciamento de dependências – Herança
Dependency Management:
Uma boa prática é definir todas as versões das dependências em um dependency
management do pom parent do projeto. Dessa forma todo projeto novo que surgir,
basta herdar desse parent que as versões já estarão compartilhadas e continuarão
centralizadas em um único projeto. Mesmo com a dependência definida no
management, os projetos ainda podem definir suas próprias versões de artefatos e o
maven dará prioridade para os mais próximos do projeto.

Gerenciamento de dependências – Agregação
Outro mecanismo é o de agregação, onde um POM principal pode definir módulos
(Multi Módulos) associados a outros POMs, que serão chamados pelo POM principal.
<groupId>br.com.adv</groupId>
<artifactId>projeto.multi.modulo</artifactId>
<packaging>pom</packaging>
<version>1.0.0.0-SNAPSHOT</version>
...
<modules>
<module>core</module>
<module>web</module>
</modules>

Gerenciamento de dependências – Árvore
Podemos ver a árvore de dependências e como elas se relacionam através do
comando mvn dependency:tree ou a partir do eclipse.

Testes
Testes unitários:
Os teste unitários do Maven são executados a partir do plugin Surefire, que executa
os testes dentro do caminho scr/test/java (caminho que poder alterado). Por padrão, o
Surefire executa os testes na fase test, além de gerar relatórios de testes em dois
formatos diferentes: .txt e .xml , que por padrão estão localizados em $
{basedir}/target/surefire-reports.
Para execução dos testes precisamos adicionar a dependência de algum framework de
teste, como TestNG e JUnit.
Caso não queiramos executar os testes usamos o parâmetro skipTests.
Exemplo: mvn install -DskipTests=true

Build
Por padrão todas as configurações dentro da tag <build> são executadas na fase
associada. Dentro do build é feito a maioria das configurações do projeto, tais como
plugins e resource e etc.

Profiles
Os perfis são configurações adicionais que por padrão não são executas. Tais perfis
quando ativados modificam o POM em tempo de compilação, e são feitos para serem
usados em conjunto ou complemento para possibilitar diferentes ambientes
(fornecendo, por exemplo, o caminho da raiz servidor no desenvolvimento, teste e
ambientes de produção).

Profiles
Quais são os diferentes tipos de perfil? Onde cada um é definido?
●
Por projeto: Definido no próprio pom.xml.
●
Por Usuário: Definido nas configurações do Maven (%USER_HOME% /
.m2/settings.xml).
●
Global: - Definido nas globais do Maven (% M2_HOME% / conf / settings.xml).

Profiles
Como um perfil pode ser acionado, e como isso varia de acordo com o tipo de perfil
que está sendo usado?
Um perfil pode ser ativado e desativado de várias formas:
●
Explicitamente
●
Através de configurações do Maven
●
Com base em variáveis de ambiente
●
Com base em configurações do SO

Profiles
Os perfis podem ser explicitamente chamados com a opção -P
Esta opção tem como argumento uma lista de perfil-ids (separado por vírgulas).
Quando esta opção é especificada, nenhum outro perfil que não esteja especificado no
argumento será ativado.
Exemplo: mvn groupId:artifactId:goal -P profile-1,profile-2

Profiles
Os perfis podem ser ativados nas configurações do Maven através da seção
<activeProfiles>. Esta seção tem uma lista de elementos <activeProfile>, cada um
contendo o id do perfil dentro.
Exemplo:
<settings>
...
<activeProfiles>
<activeProfile>profile-1</activeProfile>
</activeProfiles>
...
</settings>
Perfis listados na tag <activeProfiles> serão ativados a cada execução do projeto.

Profiles
Perfis ativados a partir de uma condição
Exemplo: Perfil será ativado caso a versão da JDK comece com “1.4" (por exemplo,
"1.4.0_08", "1.4.2_07", "1.4")
<profiles>
<profile>
<activation>
<jdk>1.4</jdk>
</activation>
...
</profile>
</profiles>

Profiles
Perfil ativado com base no SO.
<profiles>
<profile>
<activation>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
</os>
</activation>
...
</profile>
</profiles>

Profiles
Perfil ativado com base no valor de uma propriedade.
<profiles>
<profile>
<activation>
<property>
<value>test</value>
</property>
</activation>
</profile>
</profiles>
Para ativar esse perfil usamos mvn groupId:artifactId:goal -Dnome=test
Perfis do pom.xml também podem ser ativados com base em propriedades de perfis
ativos do settings.xml.

Profiles
Este exemplo irá acionar o perfil quando existir o arquivo target/generated-
sources/maven/adv.xml
<profiles>
<profile>
<activation>
<file>
<missing>target/generated-sources/maven/adv.xml</missing>
</file>
</activation>
</profile>
</profiles>

Profiles
Desativando um perfil
Podemos desativar um perfil usando ! na frente do seu identificador
Exemplo: mvn groupId:artifactId:goal -P !profile-1,!profile-2

Profiles
Se os perfis forem especificados dentro do pom.xml se tem muito mais opções, e fica
mais simples alterar ele ou sub-módulos. Escrevendo os perfis no pom.xml também
conseguimos manter a portabilidade do projeto visto que todos os arquivos estão auto
contidos no projeto.
Perfis especificados no POM podem modificar os seguintes elementos:
<repositories>
<pluginRepositories>
<dependencies>
<plugins>
<properties>
<modules>
<reporting>
<dependencyManagement>
<distributionManagement>
Um subconjunto do elemento <build>, o qual consiste em:
<defaultGoal>
<resources>
<testResources>
<finalName>-1,profile-2

Criando um novo projeto (Archetype)
Quando começamos um novo projeto, sempre criamos configurações básicas que
seguem basicamente o mesmo padrão em todos os aplicativos, como arquivos xml de
configuração, arquivos de configuração de acesso a banco de dados, classes de suítes
de testes, etc. Ao analisarmos a estrutura de um projeto novo padrão, percebemos
que o trabalho de configuração é basicamente o mesmo e que muitos dos arquivos são
copiados e colados na nova aplicação.
Para facilitar o start rápido das aplicações Maven disponibiliza os chamados
Archetypes.
Archetypes são basicamente templates de projetos pré-definidos, com alguns arquivos
e uma estrutura inicial já definida.

Criando um novo projeto (Archetype)
Esse comando irá listar os archetypes acessíveis.
mvn archetype:generate
Com esse comando reparamos que existe uma infinidade de opções de Archetypes.
Todas essas opções ficam descritas em um arquivo de configurações presente no
repositório qual o Maven aponta.

Criando um projeto a partir de um Archetype
Para criar um projeto a partir de um Archetype normalmente precisamos das
seguintes configurações:
mvn archetype:generate -DgroupId={Grupo (pacote)} -DartifactId={Nome do
Projeto} -DarchetypeArtifactId={Nome do Archetype}
DinteractiveMode=(boolean)
Exemplo de criação de uma aplicação Web:
mvn archetype:generate -DgroupId=br.com.softplan.unj.adv
-DartifactId=adv.view DarchetypeArtifactId=maven-archetype-webapp
DinteractiveMode=false

Exercícios
●
Configurar e executar um projeto com testes de integração.
●
Criar um plugin que receba um parâmetro mensagem e escreva esse parâmetro
no console.
●
Criar um Archetype que crie um projeto com as dependências do Jax-RS e Rest-
Easy, esse projeto deve vir com um endPoint com um método @Get de exemplo.

Obrigado!
André Justi
andre.justi@softplan.com.br 48 3027 8000

Apresentação maven

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Apresentação maven

Mais de André Justi

Apresentação maven