𝖂𝖎ƙ𝖎𝖊

Apache Maven

Apache Maven
Apache Maven logo.svg
Desenvolvedor Apache Software Foundation
Plataforma Multiplataforma
Versão estável 3.3.9[1] (14/11/2015)
Escrito em Java
Gênero(s) Ferramenta de compilação
Licença Apache License 2.0
Estado do desenvolvimento Ativo
Página oficial maven.apache.org

Apache Maven, ou Maven, é uma ferramenta de automação de compilação utilizada primariamente em projetos Java. Ela é similar à ferramenta Ant, mas é baseada em conceitos e trabalhos diferentes em um modo diferente. Também é utilizada para construir e gerenciar projetos escritos em C#, Ruby, Scala e outras linguagens. O projeto Maven é hospedado pela Apache Software Foundation, que fazia parte do antigo Projeto Jakarta.

O Maven utiliza um arquivo XML (POM) para descrever o projeto de software sendo construído, suas dependências sobre módulos e componentes externos, a ordem de compilação, diretórios e plug-ins necessários. Ele vem com objetivos pré-definidos para realizar certas tarefas bem definidas como compilação de código e seu empacotamento.

O Maven baixa bibliotecas Java e seus plug-ins dinamicamente de um ou mais repositórios, como o Maven 2 Central Repository, e armazena-os em uma área de cache local.[2] Este cache local de artefatos baixados pode também ser atualizado com artefatos criados por projetos locais. Repositórios públicos podem também ser atualizados.

O Maven é construído utilizando uma arquitetura baseada em plugin, que permite que ele faça uso de qualquer aplicação controlável através da entrada padrão. Teoricamente, isto permitiria qualquer um escrever plugins para fazer interface com ferramentas de construção (compiladores, ferramentas de teste de unidade, etc.) para qualquer outra linguagem. De fato, o suporte e uso para linguagens diferentes de Java tem sido mínimas. Atualmente existe um plugin para o framework .NET e é mantido, e um plugin nativo C/C++ é mantido para o Maven 2.

Exemplo

Projetos Maven são configurados usando um Project Object Model, que é armazenado em um arquivo pom.xml. A seguir está um exemplo mínimo:

<project>
  <!-- model version is always 4.0.0 for Maven 2.x POMs -->
  <modelVersion>4.0.0</modelVersion>

  <!-- project coordinates, i.e. a group of values which
       uniquely identify this project -->

  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>

  <!-- library dependencies -->

  <dependencies>
    <dependency>

      <!-- coordinates of the required library -->

      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>

      <!-- this dependency is only used for running and compiling tests -->

      <scope>test</scope>

    </dependency>
  </dependencies>
</project>

Este POM apenas define um identificador único para o projeto (coordenadas) e sua dependência do framework JUnit. No entanto, isto já é suficiente para a construção do projeto e execução dos testes de unidade associados ao projeto. O Maven realiza isto adotando a ideia de Convenção sobre configuração, isto é, ele fornece valores padrões para a configuração do projeto. A estrutura de diretórios de um projeto Maven idiomático normal possui as seguintes entradas de diretório:

Nome do diretório Propósito
project home Contém o pom.xml e todos os subdiretórios.
src/main/java Contém o código-fonte Java entregável para o projeto.
src/main/resources Contém os recursos entregáveis para o projeto, tais como arquivos de propriedades.
src/test/java Contém as classes de teste (casos de teste JUnit ou TestNG, por exemplo) para o projeto.
src/test/resources Contém os recursos necessários para teste.

Então, o comando

 mvn package

compilará todos os arquivos Java, executará quaisquer testes e empacotará o código e os recursos entregáveis no destino /my-app-1.0.jar (assumindo que o artifactld seja my-app e a versão seja 1.0).

Com a utilização do Maven, o usuário fornece apenas a configuração para o projeto, enquanto os plugins configuráveis fazem o trabalho real de compilação do projeto, limpando diretórios de destino, executando testes de unidade, gerando documentação de API e etc. Geralmente, os usuários não precisam escrever plugins. Ele contrasta com o Ant e o make, no qual um escreve procedimentos imperativos para fazer as tarefas supracitadas.

Conceitos

Project Object Model

Um Project Object Model (POM), ou em português Modelo de Projeto de Objeto, fornece todas as configurações para um único projeto. A configuração geral cobre o nome do projeto, seu proprietário e suas dependências de outros projetos. Também pode configurar fases individuais do processo de construção, que são implementados como plugins. Por exemplo, pode configurar o plugin compilador para usar a versão 1.5 do Java para compilação, ou especificar o empacotamento do projeto mesmo que algumas unidades de teste falhem.

Projetos maiores poderiam ser divididos em vários módulos, ou sub-projetos, cada um com seu próprio POM. Cada um pode então escrever um POM raiz através do qual ele pode compilar todos os módulos com um único comando. POMs também podem herdar configuração de outros POMs. Todos os POMs herdam do Super POM por padrão. O Super POM fornece configuração padrão, tal como os diretórios fonte padrões, plugins padrões e assim por diante.

Plugins

A maioria das funcionalidades do Maven está em plugins. Um plugin fornece um conjunto de objetivos que podem ser executados usando a seguinte sintaxe:

 mvn [plugin-name]:[goal-name]

Por exemplo, um projeto Java pode ser compilado com o objetivo de compilador do plugin de compilador, através da execução de mvn compiler:compile.

Há plugins Maven para construção, teste, gerenciamento de controle de fonte, execução de um servidor web, geração de arquivos de projeto Eclipse e muito mais. Plugins são introduzidos e configurados em uma seção <plugins> de um arquivo pom.xml. Alguns plugins básicos estão incluídos em todos os projetos por padrão e eles possuem configurações padrões sensíveis.

Entretanto, seria um incômodo se a construção, teste e empacotamento de um projeto necessitasse executar cada objetivo respectivo manualmente:

 mvn compiler:compile
 mvn surefire:test
 mvn jar:jar

O conceito de ciclo de vida do Maven manipula esta questão.

Plugins são o modo primário de estender o Maven. Desenvolver um plugin Maven pode ser feito através da extensão da classe org.apache.maven.plugin.AbstractMojo. Um exemplo simples é dado na página do Centro de Desenvolvedores de Plugin no site do Maven e mais exemplos detalhados são dados no Apache Maven 3 Cookbook. Código de exemplo e explicação para o plugin Maven para criar uma máquina virtual baseada em nuvem executando em um servidor de aplicação é dado no artigo Automate development and management of cloud virtual machines.

Ciclos de vida de construção

Ciclo de vida de construção é uma lista de fases nomeadas que podem ser usadas para dar ordem ao objetivo de execução. Um dos ciclos de vida padrão do Maven é o default lifecycle, que inclui as seguintes fases, nesta ordem:[3]

1. process-resources (processar recursos)
2. compile (compilar)
3. process-test-resources (processar recursos de teste)
4. test-compile (testar compilação)
5. test (testar)
6. package (empacotar)
7. install (instalar)
8. deploy (implantar)

Os objetivos fornecidos por plugins podem ser associados com diferentes fases do ciclo de vida. Por exemplo, por padrão, o objetivo "compiler:compile" está associado com a fase compile, enquanto o objetivo "surefire:test" está associado com a fase test. Considere o seguinte comando:

mvn test

Quando o comando anterior é executado, o Maven executa todos os objetivos associados com cada uma das fases acima da fase test. Em tal caso, o Maven executa o objetivo "resources:resources" associado com a fase process-resources, então "compiler:compile" e assim por diante até finalmente executar o objetivo "surefire:test".

O Maven também possui ciclos de vida padrões para limpar o projeto e para gerar um site do projeto. Se a limpeza fez parte do ciclo de vida padrão, o projeto seria limpo toda vez que eles fosse construído. Isto é claramente indesejável, pois a limpeza pode ter sido feita em seu próprio ciclo de vida.

Ciclos de vida padrão permitem que o usuário construa, teste e instale cada projeto Maven, fornecendo um único comando:

mvn install

Dependências

A seção de exemplo sugeriu ao mecanismo de manipulação de dependências do Maven. Digamos que um projeto que necessita da biblioteca Hibernate tem que declarar as coordenadas do projeto do Hibernate em seu POM. O Maven automaticamente baixará a dependência e as dependências que o próprio Hibernate precisa (chamadas dependências transitivas) e as armazenará em um repositório local do usuário. O Repositório Central do Maven 2 é usado por padrão para procurar bibliotecas, mas pode-se configurar os repositórios usados (e.g., repositórios privados de uma empresa) no POM.

Há motores de busca, como a Central Maven, que podem ser usadas para encontrar coordenadas para diferentes bibliotecas e frameworks de código aberto.

Projetos desenvolvidos em uma única máquina podem depender um do outro através do repositório local. O repositório local é uma estrutura de pasta simples que age tanto como um cache para dependências baixadas e como um local de armazenamento centralizado para construir artefatos localmente. O comando mvn install constrói um projeto e coloca seus binários em um repositório local. Então, outros projetos podem utilizar este projeto por especificação de suas coordenadas em seus POMs.

Referências

Ligações externas

Predefinição:Apache

Erro de script: Nenhum módulo desse tipo "Portal".

talvez você goste