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
Sumário 1. Project Object Model (POM)..4 Objetivos do Maven4 O que é POM?..5 Mínimo POM..5 Uma rápida visão geral estrutural6 Relacionamentos POM7 Informações sobre o Projeto.7 Configurações da Construção.7 Construção do Ambiente7 2. Estrutura de Diretório.9 3. Ciclo de Vida Maven10 Um Ciclo de Vida é feito de Fases10 Fases são Compostas de Metas11 Configurar o Projeto para usar o Ciclo de Vida.12 Empacotando.12 Ciclo de Vida de Referência13 Ciclo de Vida: Default13 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 help25 Parâmetros de Configuração.26 Mapeamento de Objetos Simples.26 Mapeamento de Objetos Complexos..26 Mapeamento de Coleções27 Listas de mapeamento 27 Mapas de mapeamento..28 2 de 41
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ório32 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 comuns38 3 de 41
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. 4 de 41
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 5 de 41
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: 6 de 41
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 7 de 41
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. 8 de 41
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 src/main/scripts src/main/webapp src/test/java src/test/resources src/test/filters src/site LICENSE.txt NOTICE.txt README.txt Arquivos de configuração Aplicação / Biblioteca de scripts Fontes da Aplicação Web Programas fontes de teste Recursos de teste Arquivos de teste para recurso de filtro Site do projeto Licença do Projeto Avisos e bibliotecas que o projeto depende Leia-me do Projeto src/ main /jav a src/ main /res ourc es src/ main /fil ters src/ main /ass embl Arquivos fontes da Aplicação / Biblioteca Recursos Aplicação / Biblioteca Arquivos de recursos de filtro Descritores de montagem 9 de 41
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. 10 de 41
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 11 de 41
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 12 de 41
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 compile process-test-resources test-compile test package install deploy resources:resources compiler:compile resources:testresources compiler:testcompile surefire:test jar:jar install:install 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 13 de 41
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 initialize generate-sources process-sources generate-resources process-resources compile process-class generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile process-test-compile test Verificar se o projeto está correto e todas as informações necessárias disponíveis Inicializar o estado de construção do projeto, por exemplo, define as propriedades ou cria os diretórios necessários Gerar qualquer código-fonte para a inclusão na compilação Processar o código fonte, por exemplo, para filtrar quaisquer valores Gerar recursos para a inclusão no pacote Copiar e processar, os recursos para o diretório destino, prontos para o empacotamento Compilar o código fonte do projeto Pós-processar os arquivos gerados a partir da compilação, por exemplo, criar os bytecodes para as classes Java Gerar qualquer código fonte de teste para inclusão na compilação Processar o código-fonte de teste, por exemplo, para filtrar quaisquer valores Criar recursos para o teste Copiar e processar, os recursos para o diretório de destino de teste Compilar o código fonte de teste no diretório de teste do destino 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 Executar os testes usando um framework de teste unitário adequado. Estes testes não devem exigir o código ser empacotado ou implantado 14 de 41
prepare-package package pre-integration-test integration-test post-integration-test verify install deploy 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) Obter o código compilado e empacotá-lo em seu formato distribuível, como um jar 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 Implantar o processo necessário em um ambiente onde os testes de integração podem ser executados Executar as ações necessárias após os testes de integração serem executados. Isso pode inclusive realizar uma limpeza no ambiente Executar todos os controles para verificar se pacote é válido e atende aos critérios de qualidade Instalar o pacote no repositório local, para uso como uma dependência em outros projetos localmente 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 clean post-clean Ciclo de Vida: site pre-site site post-site site-deploy Executar os processos necessários antes do processo de limpeza Remover todos os arquivos gerados pela compilação anterior Executar os processos necessários para finalizar o processo de limpeza Executar os processos necessários antes da geração do projeto Gerar a documentação do projeto Executar os processos necessários para finalizar a geração, e se preparar para a implantação Implantar a documentação do site gerado para o servidor Web especificado 15 de 41
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. 16 de 41
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 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. 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 17 de 41
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. 18 de 41
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 19 de 41
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: Legenda: 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!!! U O!U Faça o download, use a dependência no classpath e inclua a dependência na montagem. 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 20 de 41
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> 21 de 41
<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> 22 de 41
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 maven-archetype-archetype maven-archetype-j2ee-simple maven-archetype-mojo Descrição Contém uma amostra de um simples arquétipo Contém uma amostra Simplificado aplicação Java EE Contém uma amostra de uma amostra plugin Maven 23 de 41
maven-archetype-plugin maven-archetype-plugin-site maven-archetype-portlet maven-archetype-quickstart maven-archetype-simple maven-archetype-site maven-archetype-site-simple maven-archetype-webapp Contém uma amostra plugin Maven Contém um exemplo do site do plugin Maven Contém uma amostra JSR-268 Portlet Contém uma amostra projeto Maven Contém um projeto Maven simples 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 Contém uma amostra de um site Maven 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. 24 de 41
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> 25 de 41
<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,. 26 de 41
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> 27 de 41
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; public void execute() throws MojoExecutionException { } } 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 28 de 41
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> <artifactid>maven-myquery-plugin</artifactid> <version>1.0</version> <executions> 29 de 41
<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> 30 de 41