Maven no Java: o que é, como funciona e como usar na prática

O Maven no Java é uma das ferramentas mais importantes para organizar, construir, testar e distribuir projetos.

Quem começa a programar em Java geralmente consegue criar pequenos exemplos apenas com a IDE e o compilador. Quando o projeto cresce, porém, surgem problemas que não aparecem nos primeiros exercícios:

• onde colocar o código-fonte;
• onde colocar os testes;
• como adicionar bibliotecas externas;
• como controlar versões dessas bibliotecas;
• como compilar o projeto sempre da mesma maneira;
• como gerar um arquivo JAR;
• como executar testes automaticamente;
• como compartilhar o projeto sem enviar dezenas de arquivos JAR;
• como reproduzir o mesmo build em outra máquina ou em um servidor de integração contínua.

É nesse cenário que o Maven se torna útil.

Ele oferece convenções para a estrutura do projeto, um modelo padronizado de build e um mecanismo para trabalhar com dependências, plugins e repositórios.

O ponto central de um projeto Maven é o arquivo pom.xml, que descreve o projeto e informa ao Maven como ele deve ser construído.

Neste guia, vamos estudar Maven de forma prática. Além de entender sua origem e seus objetivos, criaremos um projeto, veremos o POM, o ciclo de vida, as dependências, os repositórios, os plugins e os comandos mais usados no dia a dia.

O objetivo não é decorar comandos. É entender o modelo que o Maven aplica aos projetos Java.

Apache Maven é uma ferramenta de gerenciamento e compreensão de projetos.

No ecossistema Java, ele é usado principalmente para:

• organizar a estrutura do projeto;
• compilar código;
• executar testes;
• empacotar aplicações e bibliotecas;
• gerenciar dependências;
• executar plugins;
• gerar relatórios;
• instalar artefatos em repositórios locais;
• publicar artefatos em repositórios remotos.

A história do Maven ajuda a entender por que ele existe.

O projeto começou como uma tentativa de simplificar o processo de build do Jakarta Turbine. Havia vários projetos com arquivos Ant diferentes entre si, e arquivos JAR eram mantidos no controle de versão.

A equipe queria uma forma mais uniforme de construir os projetos, definir claramente o que fazia parte deles, publicar informações e compartilhar bibliotecas.

Essa necessidade levou à criação de um modelo de projeto padronizado.

A documentação oficial resume os objetivos do Maven em pontos como:

• tornar o processo de build mais simples;
• fornecer um sistema uniforme de build;
• disponibilizar informações de qualidade sobre o projeto;
• incentivar boas práticas de desenvolvimento.

O Maven não elimina a necessidade de entender Java, compilação, testes ou dependências. Ele organiza e automatiza grande parte desse trabalho.

É muito comum ouvir:

Maven serve para baixar dependências.

Isso é apenas uma parte do que ele faz.

Imagine um projeto Java sem uma ferramenta de gerenciamento. Você poderia precisar:

1. procurar uma biblioteca na internet;
2. baixar o arquivo JAR;
3. copiar esse arquivo para uma pasta do projeto;
4. configurar o classpath;
5. descobrir manualmente quais outras bibliotecas aquela biblioteca precisa;
6. repetir tudo quando uma versão for atualizada;
7. garantir que todos da equipe tenham exatamente as mesmas versões.

Com Maven, você normalmente declara a dependência no POM:

<dependency>
    <groupId>org.exemplo</groupId>
    <artifactId>biblioteca</artifactId>
    <version>1.2.0</version>
</dependency>

O Maven pode resolver o artefato em um repositório configurado e incluí-lo no build.

Mas ele também cuida de outras partes do processo:

código + pom.xml + dependências
              ↓
            Maven
              ↓
   valida → compila → testa
              ↓
           empacota
              ↓
          JAR / WAR

Por isso, pense no Maven como um orquestrador do build do projeto, e não apenas como um gerenciador de bibliotecas.

A palavra build aparece constantemente em projetos Java.

Build é o processo de transformar código-fonte e recursos em um resultado utilizável.

Um fluxo simplificado pode ser:

código-fonte
    ↓
compilação
    ↓
testes
    ↓
recursos
    ↓
empacotamento
    ↓
arquivo JAR

Em aplicações reais, o build pode incluir ainda:

• geração de código;
• análise estática;
• cobertura de testes;
• testes de integração;
• empacotamento adicional;
• assinatura de artefatos;
• publicação.

O Maven organiza essas etapas usando ciclos de vida, fases e plugins.

POM significa:

Project Object Model

O arquivo pom.xml é a unidade fundamental de um projeto Maven.

Ele contém informações sobre o projeto e configurações usadas no build.

Um POM mínimo pode ser:

<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
             https://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.michel</groupId>
    <artifactId>exemplo-maven</artifactId>
    <version>1.0.0-SNAPSHOT</version>

</project>

As três coordenadas mais conhecidas são:

• 
  groupId;
• 
  artifactId;
• 
  version.

Elas ajudam a identificar um artefato.

Representa o grupo, organização ou domínio lógico responsável pelo projeto.

Exemplo:

<groupId>com.michel</groupId>

É comum usar nomes baseados em domínio invertido:

br.com.empresa
com.exemplo
org.projeto

É o identificador do projeto ou módulo.

<artifactId>sistema-clientes</artifactId>

Representa a versão:

<version>1.0.0</version>

Durante o desenvolvimento, também é comum encontrar:

<version>1.0.0-SNAPSHOT</version>

Uma forma simples de visualizar a identidade de um artefato é:

com.michel:exemplo-maven:1.0.0-SNAPSHOT

O sufixo SNAPSHOT indica normalmente uma versão em desenvolvimento.

Exemplo:

1.0.0-SNAPSHOT

Ela não representa necessariamente um lançamento final e imutável.

Quando uma versão está pronta para lançamento, um projeto pode usar algo como:

1.0.0

Essa distinção é importante em ambientes de desenvolvimento e em repositórios de artefatos.

O POM pode informar o tipo de empacotamento:

<packaging>jar</packaging>

Alguns valores comuns são:

• 
  jar;
• 
  war;
• 
  pom.

É muito usado para bibliotecas e aplicações Java.

É tradicionalmente usado para aplicações web implantadas em containers Servlet ou servidores compatíveis.

Aparece bastante em projetos pais, agregadores e estruturas multi-módulo.

Quando o packaging não é informado, o padrão é normalmente JAR.

Uma das grandes vantagens do Maven é a convenção de diretórios.

Uma estrutura típica é:

meu-projeto/
├── pom.xml
└── src/
    ├── main/
    │   ├── java/
    │   └── resources/
    └── test/
        ├── java/
        └── resources/

Contém o código Java principal.

Contém recursos da aplicação, como:

• arquivos de propriedades;
• XML;
• templates;
• configurações;
• outros arquivos carregados pela aplicação.

Contém testes.

Contém recursos usados pelos testes.

Essa padronização oferece uma vantagem prática enorme: ao abrir um projeto Maven desconhecido, você já sabe onde procurar as principais partes.

Vamos criar um projeto simples para entender o que o Maven faz.

Estrutura:

exemplo-maven/
├── pom.xml
└── src/
    └── main/
        └── java/
            └── com/
                └── michel/
                    └── App.java

Use este POM:

<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
             https://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.michel</groupId>
    <artifactId>exemplo-maven</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.release>21</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

Agora crie App.java:

package com.michel;

public class App {

    public static void main(String[] args) {
        System.out.println("Olá, Maven!");
    }
}

Esse projeto ainda não possui nenhuma biblioteca externa.

Mesmo assim, Maven já pode aplicar sua estrutura e seu ciclo de build.

Abra o terminal dentro da pasta do projeto e execute:

mvn --version

ou:

mvn -v

O comando mostra informações como:

• versão do Maven;
• versão do Java usada pelo Maven;
• caminho da instalação;
• sistema operacional.

Essa verificação é muito importante.

Sua IDE pode estar configurada com um JDK e o Maven no terminal pode estar usando outro.

Quando um projeto funciona na IDE e falha no terminal, conferir mvn --version é uma das primeiras coisas a fazer.

Na revisão deste artigo, em outubro de 2026, o projeto Apache lista o Maven 3.10.0 como a versão GA mais recente da linha 3.10.x.

A documentação também informa que Maven 3.10.0 e 3.9.16 são as duas séries GA mantidas naquele momento.

O Maven 4 ainda aparece como não GA, com versões release candidate.

Esse detalhe é importante porque artigos antigos podem recomendar versões que já chegaram ao fim do suporte.

Não trate o número presente neste artigo como eterno. Antes de instalar Maven em uma máquina nova, consulte o histórico oficial de releases.

Execute:

mvn compile

O Maven localizará o POM, aplicará a configuração e compilará o código principal.

Depois disso, aparecerá a pasta:

target/

Por exemplo:

target/
└── classes/
    └── com/
        └── michel/
            └── App.class

A pasta target contém resultados gerados pelo build.

Não coloque código-fonte importante dentro dela.

Execute:

mvn package

O Maven executará as fases necessárias até chegar a package.

O resultado pode ser:

target/exemplo-maven-1.0.0-SNAPSHOT.jar

Observe que o nome do artefato vem das informações do POM.

Esse comportamento mostra uma característica essencial do ciclo de vida:

Ao solicitar uma fase, Maven executa as fases anteriores necessárias.

Você não precisa rodar manualmente cada etapa uma por uma.

O Maven possui ciclos de vida definidos.

Os mais conhecidos são:

• 
  clean;
• 
  default;
• 
  site.

No desenvolvimento cotidiano, o ciclo default é o principal.

Algumas de suas fases são:

validate
   ↓
compile
   ↓
test
   ↓
package
   ↓
verify
   ↓
install
   ↓
deploy

Verifica se o projeto possui as informações necessárias para continuar.

Compila o código-fonte principal.

Executa os testes apropriados.

Empacota o projeto, por exemplo em JAR ou WAR.

Executa verificações necessárias para validar o pacote.

Instala o artefato no repositório local.

Publica o artefato em um repositório remoto configurado.

A documentação oficial recomenda escolher a fase de acordo com o resultado desejado.

Quer gerar o pacote?

mvn package

Quer validar o build de maneira mais abrangente?

mvn verify

Precisa que outro projeto local consuma o artefato?

mvn install

Durante o build, Maven produz arquivos dentro de target.

Para remover resultados do build anterior:

mvn clean

É comum combinar ciclos:

mvn clean package

ou:

mvn clean verify

O primeiro comando limpa o resultado anterior antes de gerar um novo pacote.

O segundo limpa e executa a validação do build até a fase verify.

O comando:

mvn install

executa as fases necessárias do ciclo default até install.

Além de compilar, testar e empacotar, o artefato é instalado no repositório Maven local.

Isso não significa “instalar o programa no Windows”.

Imagine:

Projeto A
    ↓
mvn install
    ↓
repositório Maven local
    ↓
Projeto B pode resolver A como dependência local

Essa diferença evita uma confusão bastante comum entre iniciantes.

Maven mantém um repositório local na máquina.

Em uma configuração padrão, ele costuma ficar em:

C:\Users\SEU_USUARIO\.m2\repository

~/.m2/repository

Ali podem ficar:

• dependências baixadas;
• plugins;
• metadados;
• artefatos instalados localmente.

Isso evita copiar a mesma biblioteca manualmente para cada projeto.

Quando Maven precisa de um artefato que ainda não está disponível localmente, ele pode consultá-lo em repositórios remotos configurados.

O repositório público mais conhecido é o Maven Central.

Fluxo simplificado:

pom.xml declara uma dependência
             ↓
Maven procura localmente
             ↓
não encontrou?
             ↓
consulta repositório remoto
             ↓
baixa o artefato
             ↓
armazena no repositório local
             ↓
usa no build

Empresas também podem utilizar repositórios privados, por exemplo com gerenciadores como Nexus ou Artifactory.

Isso permite controlar:

• artefatos internos;
• acesso;
• segurança;
• auditoria;
• versões;
• disponibilidade.

Dependências normalmente ficam dentro de:

<dependencies>
    ...
</dependencies>

Exemplo:

<dependencies>

    <dependency>
        <groupId>org.exemplo</groupId>
        <artifactId>biblioteca-exemplo</artifactId>
        <version>2.0.0</version>
    </dependency>

</dependencies>

As coordenadas permitem identificar exatamente qual artefato o projeto precisa.

Um dos recursos mais importantes do Maven é a resolução de dependências transitivas.

Imagine:

seu projeto
     ↓
Biblioteca A
     ↓
Biblioteca B

Seu POM declara A.

Se A depende de B, Maven pode resolver B automaticamente.

Isso reduz o trabalho manual, mas também pode criar conflitos entre versões.

Um comando essencial para investigar o que realmente entrou no projeto é:

mvn dependency:tree

Saída conceitual:

meu-projeto
+- biblioteca-a:1.0
|  \- biblioteca-c:2.0
\- biblioteca-b:3.0
   \- biblioteca-d:1.4

Quando surgir a pergunta:

Quem trouxe esta biblioteca?

A árvore de dependências é um excelente ponto de partida.

Maven permite definir em quais contextos uma dependência é necessária.

Os scopes principais incluem:

É o padrão.

A dependência fica disponível conforme as regras normais de compilação e execução.

É necessária para compilar, mas espera-se que o ambiente de execução a forneça.

Não é necessária para compilar o código principal, mas é necessária durante a execução.

É usada apenas para testes.

Exemplo:

<dependency>
    <groupId>org.exemplo</groupId>
    <artifactId>biblioteca-de-testes</artifactId>
    <version>1.0.0</version>
    <scope>test</scope>
</dependency>

Existem ainda scopes como system e import, usados em situações específicas.

A própria documentação do Maven desaconselha tratar system como solução normal, pois ele prende a dependência a um caminho físico da máquina.

Esses conceitos costumam ser misturados.

É normalmente uma biblioteca utilizada pelo projeto.

É uma extensão usada pelo Maven para executar tarefas de build.

Plugins podem:

• compilar;
• executar testes;
• gerar JAR;
• gerar documentação;
• analisar código;
• publicar artefatos.

Uma forma simples de pensar:

dependência = algo que seu projeto usa

plugin = algo que Maven usa para executar o build

É um estágio do ciclo de vida:

compile
test
package
verify
install

É uma tarefa específica fornecida por um plugin.

Quando você executa:

mvn package

está chamando uma fase.

Quando executa:

mvn dependency:tree

está chamando o goal tree de um plugin identificado pelo prefixo dependency.

No exemplo deste artigo usamos:

<properties>
    <maven.compiler.release>21</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Isso informa a release Java desejada para compilação conforme a configuração do plugin envolvido.

Mas existe um detalhe importante:

O JDK realmente utilizado pelo Maven precisa ser compatível com o projeto.

Por isso, verifique:

mvn --version

Não confie apenas no Java selecionado na IDE.

Um POM pode herdar configurações de outros POMs e do próprio Super POM do Maven.

Por isso, nem tudo que influencia o build aparece explicitamente no arquivo que você está olhando.

Para visualizar o POM efetivo:

mvn help:effective-pom

Esse comando é muito útil quando:

• uma versão parece surgir sem estar declarada;
• um plugin foi herdado;
• existe um POM pai;
• você quer compreender propriedades efetivas;
• está investigando um comportamento inesperado.

É uma ferramenta de diagnóstico, não apenas uma curiosidade.

Em equipes, pode acontecer:

desenvolvedor A → Maven versão X
desenvolvedor B → Maven versão Y
servidor CI     → Maven versão Z

O Maven Wrapper ajuda a padronizar a execução.

Projetos configurados com Wrapper costumam possuir:

mvnw
mvnw.cmd
.mvn/

Em vez de depender exclusivamente de uma instalação Maven global, você pode executar:

.\mvnw.cmd verify

./mvnw verify

Isso facilita a reprodução do build por desenvolvedores e pipelines.

Projetos maiores frequentemente utilizam dependencyManagement.

Ele não é o mesmo que dependencies.

Declara as bibliotecas que o módulo utiliza.

Centraliza regras e versões de dependências.

Exemplo:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.exemplo</groupId>
            <artifactId>biblioteca</artifactId>
            <version>2.5.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Um módulo filho pode então declarar:

<dependency>
    <groupId>org.exemplo</groupId>
    <artifactId>biblioteca</artifactId>
</dependency>

e receber a versão gerenciada, dependendo da hierarquia do projeto.

Esse recurso aparece bastante em aplicações corporativas.

BOM significa:

Bill of Materials

No Maven, um BOM permite trabalhar com um conjunto coordenado de versões.

Em vez de escolher manualmente a versão de cada biblioteca de um ecossistema, o projeto pode importar um BOM responsável por manter versões compatíveis.

Esse conceito aparece bastante em frameworks modernos.

O importante para o iniciante é compreender:

BOM não é uma biblioteca comum; ele é usado para gerenciamento consistente de versões.

Maven também trabalha com projetos formados por vários módulos.

Exemplo:

sistema/
├── pom.xml
├── dominio/
│   └── pom.xml
├── persistencia/
│   └── pom.xml
└── api/
    └── pom.xml

O POM agregador pode declarar:

<modules>
    <module>dominio</module>
    <module>persistencia</module>
    <module>api</module>
</modules>

Isso permite construir vários módulos de forma coordenada.

Não é necessário começar os estudos por multi-módulo, mas é importante saber que Maven vai muito além de um único JAR.

Quem estuda Spring Boot encontra Maven rapidamente.

Em um projeto Spring Boot, Maven pode cuidar de:

• starters;
• dependências;
• compilação;
• testes;
• empacotamento;
• plugins;
• geração de aplicação executável.

Por isso, entender Maven torna mais fácil compreender um projeto Spring.

Quando abrir um pom.xml de Spring Boot, procure identificar:

• parent;
• properties;
• dependencies;
• dependencyManagement;
• build;
• plugins.

Não trate o POM como um arquivo mágico criado pela IDE.

Leia o arquivo e tente entender de onde vêm as configurações.

Maven não é a única ferramenta de build do ecossistema Java.

Gradle é outra opção bastante conhecida.

De forma simplificada:

• forte uso de convenções;
• configuração tradicional em XML;
• enorme presença em projetos Java;
• ecossistema maduro;
• modelo bastante previsível.

• scripts em Kotlin ou Groovy;
• alta flexibilidade;
• forte presença em projetos JVM e Android;
• modelo de build diferente.

Não existe uma resposta universal para “qual é melhor”.

Uma pergunta mais útil é:

Qual ferramenta este projeto usa e eu consigo entender como o build funciona?

Para quem trabalha com Java profissionalmente, conhecer Maven continua sendo extremamente útil.

Não.

São ferramentas para problemas diferentes.

Controla versões do código.

Gerencia o build e diversos aspectos do projeto.

Fluxo comum:

Git
 ↓
código + pom.xml
 ↓
Maven
 ↓
compila + testa + empacota
 ↓
artefato

É normal usar os dois juntos.

Também não.

Você pode executar Maven:

• pela linha de comando;
• pelo IntelliJ IDEA;
• pelo Eclipse;
• pelo VS Code;
• em um servidor CI.

Um projeto bem configurado não deve depender exclusivamente de uma sequência de cliques em uma IDE específica.

Ter um build reproduzível pelo terminal é uma vantagem importante.

Na maioria dos projetos Maven, não.

Em vez de versionar arquivos binários manualmente, o projeto normalmente registra as coordenadas das dependências no POM.

Exemplo conceitual:

abordagem manual

projeto/
├── lib/
│   ├── biblioteca-a.jar
│   ├── biblioteca-b.jar
│   └── biblioteca-c.jar
└── src/


abordagem Maven

projeto/
├── pom.xml
└── src/

Existem exceções, mas copiar JARs manualmente não deve ser a solução padrão quando a biblioteca está disponível em um repositório apropriado.

Você não precisa decorar todos no primeiro dia.

Uma base útil é conhecer:

clean
test
package
verify
install
dependency:tree

Imagine que você clonou um projeto Maven.

Primeiro, verifique o ambiente:

mvn --version

Depois tente validar o build:

mvn clean verify

Se houver problema de dependência:

mvn dependency:tree

Se não entender de onde veio uma configuração:

mvn help:effective-pom

Se precisar gerar apenas o pacote:

mvn package

Se outro projeto local precisar consumir aquele artefato:

mvn install

Esse pequeno conjunto cobre grande parte das situações comuns.

Quando o build falhar, não adote a estratégia de apagar arquivos aleatoriamente até funcionar.

Use um processo.

Muitas mensagens posteriores são apenas consequência da primeira falha.

mvn --version

Confira Maven e Java.

mvn clean verify

mvn dependency:tree

mvn help:effective-pom

Logs muito extensos podem dificultar a análise.

Primeiro entenda a mensagem principal e só então aumente a verbosidade.

A pasta target contém resultados gerados.

Ela pode ser removida por:

mvn clean

Não coloque código-fonte importante ali.

Execute:

mvn --version

A IDE e o terminal podem estar usando JDKs diferentes.

Antes de criar uma pasta lib, verifique se a dependência possui coordenadas em um repositório confiável.

Conflitos de versão e dependências transitivas ficam mais claros com:

mvn dependency:tree

mvn install instala o artefato no repositório Maven local.

Versão mais nova não significa atualização automática sem análise.

Leia notas de versão, valide compatibilidade e execute testes.

Aprenda a validar o projeto pelo terminal.

Isso ajuda a separar problemas da IDE de problemas reais do build.

Se uma versão não aparece no seu POM, ela pode ter vindo de parent, dependencyManagement, BOM ou Super POM.

Use:

mvn help:effective-pom

Em projetos antigos, era comum encontrar:

• arquivos JAR versionados junto com o código;
• scripts Ant específicos para cada projeto;
• estruturas de diretórios diferentes;
• configurações dependentes da máquina;
• documentação incompleta sobre como construir o sistema.

Maven ajudou a popularizar uma abordagem baseada em:

• convenções;
• metadados;
• coordenadas;
• repositórios;
• plugins reutilizáveis;
• ciclo de vida padronizado.

Isso não significa que Maven seja perfeito.

POMs grandes podem ficar extensos e builds complexos exigem conhecimento.

Mesmo assim, a previsibilidade oferecida pelas convenções continua sendo uma das maiores vantagens.

Maven é especialmente útil quando você precisa:

• gerenciar dependências;
• automatizar build;
• padronizar diretórios;
• executar testes;
• gerar JAR ou WAR;
• trabalhar em equipe;
• integrar com CI/CD;
• publicar bibliotecas;
• usar frameworks com forte integração Maven.

Para um único arquivo Java de poucas linhas, Maven pode ser desnecessário.

Mas quando aparecem testes, dependências e empacotamento, seu valor fica evidente.

Crie um projeto chamado:

calculadora-maven

Use:

groupId: com.seunome
artifactId: calculadora-maven
version: 1.0.0-SNAPSHOT
Java: 21

Crie:

package com.seunome;

public class Calculadora {

    public int somar(int a, int b) {
        return a + b;
    }

    public int subtrair(int a, int b) {
        return a - b;
    }
}

Depois execute:

mvn clean compile

Em seguida:

mvn package

Agora investigue a pasta target.

Responda:

1. onde ficou o arquivo .class?
2. qual JAR foi gerado?
3. de onde veio o nome do JAR?
4. o que acontece depois de mvn clean?
5. o que muda no nome do artefato se você alterar a versão no POM?

Esse exercício ensina mais do que simplesmente decorar comandos.

Abra um projeto Java real que use Maven.

Tente localizar:

groupId
artifactId
version
packaging
properties
dependencies
dependencyManagement
build
plugins
parent
modules

Nem todo projeto terá todos esses elementos.

O objetivo é começar a enxergar o POM como uma descrição do projeto, e não como um grande bloco de XML misterioso.

Não.

É possível compilar e executar Java sem Maven.

Entretanto, Maven é muito usado profissionalmente porque resolve problemas de build, dependências e padronização.

Não.

Maven é uma ferramenta.

O POM é um documento XML declarativo.

É o Project Object Model.

Ele contém informações do projeto e configurações usadas pelo Maven.

Ela é usada para configurações do usuário Maven e, normalmente, para o repositório local.

Artefatos remotos podem ser baixados novamente quando necessários, mas apagar todo o repositório local não deve ser a resposta automática para qualquer erro.

Primeiro investigue a causa.

É um dos principais repositórios públicos de artefatos usados pelo ecossistema Maven.

Executa o ciclo clean e depois as fases necessárias até install, conforme o build configurado.

Depende do objetivo:

• quer gerar o pacote: package;
• quer validar o build até as verificações configuradas: verify;
• precisa instalar o artefato no repositório local: install.

Não use install apenas por hábito quando verify já atende sua necessidade.

Seu foco histórico é o ecossistema Java/JVM, mas o sistema de plugins permite integrar outras ferramentas e tarefas ao build.

Antes de considerar este assunto concluído, tente explicar sem consultar o artigo:

• o que é Maven;
• o que significa build;
• para que serve o POM;
• o que são groupId, artifactId e version;
• o que significa SNAPSHOT;
• onde fica o código principal;
• onde ficam os testes;
• para que serve target;
• diferença entre clean, package, verify e install;
• o que é repositório local;
• o que é repositório remoto;
• o que é Maven Central;
• o que é dependência transitiva;
• para que serve dependency:tree;
• diferença entre dependência e plugin;
• diferença entre fase e goal;
• o que é POM efetivo;
• por que Maven Wrapper é útil;
• o que dependencyManagement faz;
• o que é um BOM.

Se você consegue explicar esses pontos com suas próprias palavras, já possui uma base de Maven muito mais útil do que apenas saber executar mvn install.

Guarde este fluxo:

            pom.xml
               │
               ├── identidade
               ├── propriedades
               ├── dependências
               └── plugins
               │
               ▼
             Maven
               │
      ┌────────┼─────────┐
      ▼        ▼         ▼
   compile    test     package
      │        │         │
      └────────┴─────────┘
               │
               ▼
            verify
               │
               ▼
            install
               │
               ▼
             deploy

A ideia central é:

Maven fornece um modelo padronizado para descrever, construir, testar e distribuir projetos.

O Maven nasceu para reduzir a desorganização do processo de build e criar uma maneira mais uniforme de trabalhar com projetos Java.

Sua importância não está apenas em baixar bibliotecas.

Ele conecta:

estrutura do projeto
       +
     pom.xml
       +
   dependências
       +
     plugins
       +
 ciclo de vida
       ↓
 build reproduzível

A melhor maneira de aprender Maven é utilizá-lo.

Crie um projeto pequeno, execute os comandos pelo terminal, examine a pasta target, veja a árvore de dependências e leia o POM.

Depois faça o mesmo em um projeto Spring Boot.

Quando você deixa de enxergar Maven como “aquele XML enorme” e passa a compreender seu modelo, o funcionamento de muitos projetos Java profissionais começa a fazer sentido.

• Apache Maven — Introduction: https://maven.apache.org/what-is-maven
  
• Apache Maven — Getting Started Guide: https://maven.apache.org/guides/getting-started/index.html
  
• Apache Maven — Maven in 5 Minutes: https://maven.apache.org/guides/getting-started/maven-in-five-minutes
  
• Apache Maven — Introduction to the POM: https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
  
• Apache Maven — Build Lifecycle: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
  
• Apache Maven — Dependency Mechanism: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
  
• Apache Maven — Standard Directory Layout: https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
  
• Apache Maven — Release History: https://maven.apache.org/docs/history.html
  

Depois deste conteúdo, avance para:

1. criar um projeto Maven com testes JUnit;
2. estudar Maven Surefire Plugin;
3. aprofundar dependencyManagement e BOM;
4. criar um projeto multi-módulo;
5. utilizar Maven Wrapper;
6. analisar o POM de um projeto Spring Boot;
7. integrar Maven em pipelines de CI/CD.

Ideia central: Maven vale mais quando você entende o modelo de projeto e o ciclo de build, em vez de apenas decorar uma lista de comandos.

Veja também: mais conteúdos sobre Java.

Maven: The Definitive Guide (English Edition)

⭐ 4.2/5

Maven: The Definitive Guide (English Edition). Produto recomendado para estudos, programação e produtividade.

R$ 222,74 R$ 178,19

Ver na Amazon Como afiliado, posso receber comissão por compras qualificadas.