Apache Maven - Apache Maven

Apache Maven
Apache Maven logo.svg
Desenvolvedor (s) Apache Software Foundation
lançamento inicial 13 de julho de 2004 ; 17 anos atrás ( 13/07/2004 )
Versão estável
3.8.3 / 27 de setembro de 2021 ; 14 dias atrás ( 2021-09-27 )
Repositório Repositório Maven
Escrito em Java
Modelo Ferramenta de construção
Licença Licença Apache 2.0
Local na rede Internet maven .apache .org

Maven é uma ferramenta de automação de construção usada principalmente para projetos Java . O Maven também pode ser usado para construir e gerenciar projetos escritos em C # , Ruby , Scala e outras linguagens. O projeto Maven é hospedado pela Apache Software Foundation , onde antes fazia parte do Projeto Jakarta .

O Maven aborda dois aspectos da construção de software: como o software é construído e suas dependências. Ao contrário das ferramentas anteriores, como o Apache Ant , ele usa convenções para o procedimento de construção. Apenas exceções precisam ser especificadas. Um arquivo XML descreve o projeto de software que está sendo construído, suas dependências em outros módulos e componentes externos, a ordem de construção, diretórios e plug-ins necessários . Ele vem com metas predefinidas para executar certas tarefas bem definidas, como compilação de código e seu empacotamento. O Maven faz download dinamicamente de bibliotecas Java e plug-ins Maven de um ou mais repositórios, como o Repositório Central Maven 2, e os armazena em um cache local. Este cache local de artefatos baixados também pode ser atualizado com artefatos criados por projetos locais. Os repositórios públicos também podem ser atualizados.

O Maven é construído usando uma arquitetura baseada em plug-in que permite fazer uso de qualquer aplicativo controlável por meio de entrada padrão. Um plugin nativo C / C ++ é mantido para Maven 2.

Tecnologias alternativas como Gradle e sbt como ferramentas de construção não dependem de XML , mas mantêm os conceitos-chave introduzidos pelo Maven. Com o Apache Ivy , também foi desenvolvido um gerenciador de dependência dedicado que também oferece suporte a repositórios Maven.

Apache Maven tem suporte para compilações reproduzíveis .

História

O número de artefatos no repositório central do Maven cresceu rapidamente

O Maven, criado por Jason van Zyl, começou como um subprojeto da Apache Turbine em 2002. Em 2003, ele foi votado e aceito como um projeto de nível superior da Apache Software Foundation . Em julho de 2004, o lançamento do Maven foi o primeiro marco crítico, v1.0. O Maven 2 foi declarado v2.0 em outubro de 2005, após cerca de seis meses em ciclos beta. O Maven 3.0 foi lançado em outubro de 2010, sendo compatível com versões anteriores do Maven 2.

As informações do Maven 3.0 começaram a surgir em 2008. Depois de oito lançamentos alfa, a primeira versão beta do Maven 3.0 foi lançada em abril de 2010. O Maven 3.0 retrabalhou a infraestrutura principal do Project Builder, resultando na representação baseada em arquivo do POM sendo desacoplada de seu interior representação do objeto de memória. Isso expandiu a possibilidade dos complementos do Maven 3.0 aproveitarem os arquivos de definição de projeto não baseados em XML. As linguagens sugeridas incluem Ruby (já em protótipo privado de Jason van Zyl), YAML e Groovy .

Atenção especial foi dada para garantir a compatibilidade com versões anteriores do Maven 3 para o Maven 2. Para a maioria dos projetos, o upgrade para o Maven 3 não exigirá nenhum ajuste na estrutura do projeto. O primeiro beta do Maven 3 viu a introdução de um recurso de construção paralela que aproveita um número configurável de núcleos em uma máquina com vários núcleos e é especialmente adequado para grandes projetos com vários módulos.

Sintaxe

Uma estrutura de diretório para um projeto Java gerado automaticamente pelo Maven

Os projetos Maven são configurados usando um Project Object Model (POM) , que é armazenado em um pom.xml-file. Um exemplo de arquivo se parece com:

<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 define apenas um identificador único para o projeto ( coordenadas ) e sua dependência da estrutura JUnit . No entanto, isso já é suficiente para construir o projeto e executar os testes de unidade associados ao projeto. O Maven consegue isso abraçando a ideia de Convenção sobre a Configuração , ou seja, o Maven fornece valores padrão para a configuração do projeto.

A estrutura de diretório de um projeto Maven idiomático normal tem as seguintes entradas de diretório:

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

O comando mvn packagecompilará todos os arquivos Java, executará quaisquer testes e empacotará o código e os recursos que podem ser entregues target/my-app-1.0.jar(assumindo que o artifactId seja my-app e a versão seja 1.0).

Usando o Maven, o usuário fornece apenas a configuração para o projeto, enquanto os plug-ins configuráveis ​​fazem o trabalho real de compilar o projeto, limpar diretórios de destino, executar testes de unidade, gerar documentação de API e assim por diante. Em geral, os usuários não devem ter que escrever plug-ins sozinhos. Compare isso com Ant e make , em que se escreve procedimentos imperativos para fazer as tarefas mencionadas acima.

Projeto

Modelo de Objeto de Projeto

Um Project Object Model (POM) fornece toda a configuração para um único projeto. A configuração geral cobre o nome do projeto, seu proprietário e suas dependências em outros projetos. Também é possível configurar fases individuais do processo de construção, que são implementadas como plug-ins . Por exemplo, pode-se configurar o plug-in do compilador para usar o Java versão 1.5 para compilação ou especificar o empacotamento do projeto mesmo se alguns testes de unidade falharem.

Projetos maiores devem ser divididos em vários módulos, ou subprojetos, cada um com seu próprio POM. Pode-se então escrever um POM raiz através do qual se pode compilar todos os módulos com um único comando. Os POMs também podem herdar a configuração de outros POMs. Todos os POMs herdam do Super POM por padrão. O Super POM fornece configuração padrão, como diretórios de origem padrão, plug-ins padrão e assim por diante.

Plug-ins

A maior parte da funcionalidade do Maven está em plug-ins . Um plugin fornece um conjunto de objetivos que podem ser executados usando o comando mvn [plugin-name]:[goal-name]. Por exemplo, um projeto Java pode ser compilado com o objetivo de compilação do plug-in do compilador executando mvn compiler:compile.

Existem plug-ins Maven para construção, teste, gerenciamento de controle de origem, execução de um servidor web, geração de arquivos de projeto Eclipse e muito mais. Os plug-ins são introduzidos e configurados em uma seção <plugins> de um pom.xmlarquivo. Alguns plug-ins básicos são incluídos em todos os projetos por padrão e têm configurações padrão razoáveis.

No entanto, seria complicado se a sequência de construção arquetípica de construção, teste e empacotamento de um projeto de software exigisse a execução de cada meta manualmente:

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

O conceito de ciclo de vida do Maven trata desse problema.

Plugins são a principal forma de estender o Maven. O desenvolvimento de um plugin Maven pode ser feito estendendo a classe org.apache.maven.plugin.AbstractMojo. O código de exemplo e a explicação de um plug-in Maven para criar uma máquina virtual baseada em nuvem executando um servidor de aplicativos são fornecidos no artigo Automatizar o desenvolvimento e gerenciamento de máquinas virtuais em nuvem .

Crie ciclos de vida

O ciclo de vida da construção é uma lista de fases nomeadas que podem ser usadas para dar ordem à execução do objetivo. Um dos ciclos de vida padrão do Maven é o ciclo de vida padrão , que inclui as seguintes fases, nesta ordem:

  • validar
  • gerar-fontes
  • fontes de processo
  • gerar recursos
  • recursos de processo
  • compilar
  • fontes de teste de processo
  • recursos de teste de processo
  • teste-compilação
  • teste
  • pacote
  • instalar
  • implantar

As metas fornecidas por plug-ins podem ser associadas a diferentes fases do ciclo de vida. Por exemplo, por padrão, o objetivo "compilador: compilar" está associado à fase "compilar", enquanto o objetivo "infalível: teste" está associado à fase "teste". Quando o mvn testcomando é executado, o Maven executa todos os objetivos associados a cada uma das fases até e incluindo a fase de "teste". Nesse caso, o Maven executa a meta "recursos: recursos" associada à fase "recursos do processo", depois "compilador: compilar" e assim por diante até que finalmente execute a meta "infalível: teste".

O Maven também possui fases padrão para a limpeza do projeto e para a geração de um local do projeto. Se a limpeza fizesse parte do ciclo de vida padrão, o projeto seria limpo sempre que fosse construído. Isso é claramente indesejável, então a limpeza teve seu próprio ciclo de vida.

Os ciclos de vida padrão permitem aos usuários novos em um projeto a capacidade de construir, testar e instalar com precisão cada projeto Maven emitindo um único comando mvn install. Por padrão, o Maven empacota o arquivo POM nos arquivos JAR e WAR gerados. Ferramentas como diet4j podem usar essas informações para resolver recursivamente e executar módulos Maven em tempo de execução sem exigir um "uber" -jar que contém todo o código do projeto.

Dependências

Um recurso central do Maven é o gerenciamento de dependências . O mecanismo de manipulação de dependência do Maven é organizado em torno de um sistema de coordenadas que identifica artefatos individuais, como bibliotecas de software ou módulos. O exemplo POM acima faz referência às coordenadas JUnit como uma dependência direta do projeto. Um projeto que precisa, digamos, da biblioteca do Hibernate simplesmente precisa declarar as coordenadas do projeto do Hibernate em seu POM. O Maven baixará automaticamente a dependência e as dependências que o próprio Hibernate precisa (chamadas de dependências transitivas ) e as armazenará no repositório local do usuário. O Repositório Central Maven 2 é usado por padrão para pesquisar bibliotecas, mas é possível configurar os repositórios a serem usados ​​(por exemplo, repositórios privados da empresa) dentro do POM.

A diferença fundamental entre Maven e Ant é que o design do Maven considera todos os projetos como tendo uma certa estrutura e um conjunto de fluxos de trabalho de tarefas suportados (por exemplo, obter recursos do controle de origem, compilar o projeto, teste de unidade, etc.). Embora a maioria dos projetos de software em vigor apóie essas operações e realmente tenha uma estrutura bem definida, o Maven requer que essa estrutura e os detalhes de implementação da operação sejam definidos no arquivo POM. Portanto, o Maven se baseia em uma convenção sobre como definir projetos e na lista de fluxos de trabalho que geralmente são suportados em todos os projetos.

Existem mecanismos de pesquisa como o The Central Repository Search Engine, que pode ser usado para encontrar coordenadas para diferentes bibliotecas e estruturas de código aberto.

Projetos desenvolvidos em uma única máquina podem depender uns dos outros por meio do repositório local. O repositório local é uma estrutura de pasta simples que atua como um cache para dependências baixadas e como um local de armazenamento centralizado para artefatos construídos localmente. O comando Maven mvn installconstrói um projeto e coloca seus binários no repositório local. Então, outros projetos podem utilizar este projeto especificando suas coordenadas em seus POMs.

Interoperabilidade

Add-ons para vários ambientes de desenvolvimento integrado (IDE) populares direcionados à linguagem de programação Java existem para fornecer integração do Maven com o mecanismo de construção do IDE e ferramentas de edição de código-fonte, permitindo ao Maven compilar projetos de dentro do IDE e também definir o classpath para autocompletar código, destacando erros do compilador, etc.

Exemplos de IDEs populares que apoiam o desenvolvimento com Maven incluem:

Esses complementos também fornecem a capacidade de editar o POM ou usar o POM para determinar o conjunto completo de dependências de um projeto diretamente no IDE.

Alguns recursos integrados de IDEs são perdidos quando o IDE não executa mais a compilação. Por exemplo, o JDT do Eclipse tem a capacidade de recompilar um único arquivo de origem Java após sua edição. Muitos IDEs trabalham com um conjunto simples de projetos em vez da hierarquia de pastas preferida pelo Maven. Isso complica o uso de sistemas SCM em IDEs ao usar Maven.

Veja também

Referências

Leitura adicional

links externos