Como funciona o processo de build com Maven: guia prático de maven build e mvn compile

Se você está procurando saber como rodar um maven build, utilizar o comando mvn compile, ou simplesmente entender como funciona o build de um projeto Maven, este artigo vai te ensinar o passo a passo, exemplos práticos de build com Maven e responder dúvidas como: 'como compilar um projeto Maven' ou 'como usar o comando mvn'. 

Este post, escrito em 2008, foi atualizado neste ano de 2026, tanto na formatação como no conteúdo. 

Muitas pessoas migram seus projetos para o Maven, mas acabam arrumando mais problemas que soluções, pois não conseguem configurá-lo corretamente, e acabam desistindo e fazendo tudo na mão, ou voltando para o Ant. 

Mas, se você conseguir ajustar as configurações, o Maven vai te ajudar muito e vai compensar todos os (poucos) problemas que ele eventualmente causa. No início do uso do Maven, espere formar com ele uma relação de amor e ódio. 

Como instalar o Maven e preparar seu ambiente 

Para começar a usar o Maven, tudo o que você precisa fazer é baixá-lo e configurar umas poucas variáveis de ambiente. Depois de ter feito isso, é só digitar mvn [target] na linha de comando. Alguns sistemas operacionais já te oferecem essa instalação por meio do macport ou apt-get. 

O que é Maven em Java e como funciona a configuração do maven project 

A unidade básica de configuração do Maven é um arquivo chamado pom.xml, que deve ficar na raiz do seu projeto. Ele é um arquivo conhecido como Project Object Model: lá você declara a estrutura, dependências e características do seu projeto. 

A ideia é semelhante com o build.xml do Ant: você deixa o pom.xml na raiz do seu projeto para poder chamar as targets de build do seu projeto. O menor arquivo pom.xml válido é o seguinte:  

<project>  
<modelVersion>4.0.0</modelVersion>     
     <groupId>br.com.caelum</groupId>    
     <artifactId>teste</artifactId>     
     <version>1.0</version>   
</project>

Que contém apenas a identificação do projeto e uma informação a mais: modelVersion, que é a identificação da versão do arquivo pom.xml e deve ser sempre 4.0.0. A identificação do projeto consiste em três informações: 

• groupId: um identificador da empresa/grupo ao qual o projeto pertence. Geralmente o nome do site da empresa/grupo ao contrário. Ex: br.com.alura. 
• artifactId: o nome do projeto. Ex: teste. 
• version: a versão atual do projeto. Ex: 1.0-SNAPSHOT. 

Como funciona o gerenciamento de dependências no Maven build 

Essas informações são usadas em muitos lugares, como o controle de dependências, que é, na minha opinião, a funcionalidade mais útil do Maven. Para dizer que o log4j 2.23.1 (ou versão mais recente segura) é uma dependência da sua aplicação, é só acrescentar no seu pom as linhas:  

<project>   
...     
<dependencies>      
     <dependency> 
         <groupId>org.apache.logging.log4j</groupId>  
         <artifactId>log4j-core</artifactId>  
         <version>2.23.1</version>    
     </dependency>    
    </dependencies>   
...   
</project>

Quando necessário, o Maven vai baixar para você o JAR do log4j 1.2.15 e todas as suas dependências, e vai colocá-las no classpath da sua aplicação durante os builds, testes etc. Ou seja, você não precisa mais entrar no site do log4j, baixar um “.zip” com vários JARs e ter que procurar quais JARs devem ser colocados no classpath! 

Como o Maven executa o processo de build (mvn build e mvn compile) 

No Repositório de Bibliotecas do Maven, você encontra os JARs que você pode colocar como dependência do seu projeto, e o pedaço de XML que você deve copiar e colar dentro da tag <dependencies> do seu pom para incluir essas bibliotecas. 

Todos os JARs baixados pelo Maven são guardados na pasta repository dentro da M2_HOME que você configurou quando instalou o Maven. Assim, se mais de um projeto seu depende do mesmo JAR, ele não é baixado de novo. 

A grande diferença entre o build.xml do Ant e o pom.xml do Maven é o paradigma. No Ant, usamos esse XML praticamente como uma linguagem de programação, em que você dá comandos em relação ao build do projeto. 

No Maven, usamos o XML para definir a estrutura do projeto, e, a partir dessas declarações, o Maven possui targets bem definidos que usam essas informações para saber como realizar aquela tarefa. 

Um exemplo: para compilar com o Ant, criamos um target que chama o javac, mas para compilar com o Maven usamos um target já existente (não o criamos), e ele vai usar a informação que define onde está o código-fonte e para onde ele deve ser compilado (sendo que muitas dessas informações possuem convenções e defaults, e nem precisam ser configuradas). 

Como usar plugins no Maven build para expandir funcionalidades 

Além dos principais targets do Maven, você pode executar targets de plugins. Basta digitar o seguinte comando no terminal: 

mvn [nomedoplugin]:[target] 

E então o Maven baixa o plugin, se necessário, e executa a target para você. Existe uma lista bem grande de plugins do Maven e uma boa parte desses plugins podem ser usados sem nenhuma configuração adicional no seu pom. 

Para dar um exemplo de plugin do Maven, nada melhor do que o plugin que cria um protótipo de projeto do Maven: o Archetype. É bem parecido com o scaffold do Ruby: ele cria um protótipo de projeto a partir de um modelo escolhido. O jeito mais fácil de usar esse plugin é digitando na linha de comando: 

mvn archetype:generate 

E então o Archetype vai perguntar qual é o tipo de projeto que você deseja, o groupID, artifactID, version e o pacote referentes ao seu projeto. Depois disso, você terá uma estrutura de projeto pronta para ser usada. 

Por exemplo, se você escolheu o tipo de projeto maven-archetype-quickstart, o Archetype vai criar uma estrutura de pastas parecida com a seguinte: 

teste 
|-- pom.xml 
`-- src 
    |-- main 
    |   `-- java 
|   `-- br 
    |       `-- com 
    |           `-- caelum 
    |               `-- teste 
    |                   `-- App.java 
    `-- test 
    `-- java 
         `-- br 
            `-- com 
                `-- caelum 
                    `-- teste 
                        `-- AppTest.java

A partir dessa estrutura inicial, você pode dar continuidade ao desenvolvimento do seu projeto.

O código de teste já vem separado do código principal, e o JUnit é incluso como dependência padrão. Você também pode criar as pastas src/main/resources e src/test/resources para colocar os recursos (arquivos de configuração, de teste, etc.) do código principal e do de testes, respectivamente. 

Tudo o que estiver dentro dessas pastas será copiado automaticamente para o diretório de saída das classes compiladas, sem que seja necessária configuração adicional. 

Como personalizar a estrutura de um maven project para build 

Se você, por algum motivo, não gostou da estrutura que o Maven criou, ou está querendo migrar um projeto para o Maven que não segue essa estrutura, você pode configurar os diretórios do projeto acrescentando algumas linhas no pom: 

<project> 
... 
<build> 
<sourceDirectory> 
   ${project.basedir}/src/java/main 
</sourceDirectory> 
<testSourceDirectory> 
   ${project.basedir}/src/java/test 
</testSourceDirectory> 
<resources> 
       <resource> 
              <directory> 
                ${project.basedir}/src/resources/main 
              </directory> 
       </resource> 
</resources> 
<testResources> 
       <testResource> 
              <directory> 
                ${project.basedir}/src/resources/test 
              </directory> 
       </testResource> 
 
 
... 

Nesse exemplo, o diretório principal de código e de recursos estarão em `src/java/main` e `src/resources/main` respectivamente, e os diretórios de teste em `src/java/test` e `src/resources/test`. 

Entendendo o ciclo de vida do Maven Build: fases, comandos e exemplos 

Agora, com um projeto Maven já preparado, vamos para a principal funcionalidade: o build. O build do Maven é baseado no conceito de ciclo de vida: o processo de construção e distribuição da sua aplicação é dividido em partes bem definidas chamadas fases, seguindo um ciclo. O ciclo padrão é o seguinte: 

• compile - compila o código-fonte do projeto; 
• test - executa os testes unitários do código compilado, usando uma ferramenta de testes unitários, como o junit; 
• package - empacota o código compilado de acordo com o empacotamento escolhido, por exemplo, em JAR; 
• integration-test - processa e faz o deploy do pacote em um ambiente onde os testes de integração podem ser rodados; 
• install - instala o pacote no repositório local, para ser usado como dependência de outros projetos locais; 
• deploy - feito em ambiente de integração ou de release, copia o pacote final para um repositório remoto para ser compartilhado entre desenvolvedores e projetos. 

É possível executar qualquer uma dessas fases pelo terminal, utilizando o comando: 

mvn [fase] 

Por exemplo, ao executar mvn package, o Maven irá processar automaticamente todas as fases anteriores do ciclo até chegar na fase package. Uma lista completa das fases do ciclo de vida do Maven pode ser consultada na documentação oficial. 

Algumas das fases do ciclo possuem plugins associadas a elas, e esses plugins são executados assim que a fase é chamada para ser executada. Você pode também registrar plugins para rodarem em qualquer fase do ciclo, conseguindo, assim, personalizar o build do seu projeto facilmente. 

Por exemplo, se você quiser criar um jar com o código fonte do projeto, e que esse jar seja gerado depois que o projeto foi empacotado, é só acrescentar no seu pom: 

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

Assim, o plugin Source vai executar seu goal jar na fase package do ciclo de vida. É como se fosse chamado mvn source:jar quando o build passa pela fase de package.

A fase package já possui um plugin associado a ela: o jar:jar (supondo que é um projeto jar), então o plugin source só será executado depois do jar:jar. 

Em geral, se você registrar mais de um plugin para a mesma fase, eles serão executados na ordem em que forem declarados. O jeito de configurar o plugin para colocá-lo dentro de uma fase do ciclo geralmente está no site principal do plugin, na seção Usage. 

Mais plugins úteis no dia a dia 

O Maven possui ainda outras funcionalidades interessantes, como geração de relatórios. Alguns plugins também merecem uma atenção especial, como: 

• O Eclipse que gera informações de projeto para o eclipse (`.classpath` e `.project`); 
• O Antrun, que te permite executar código Ant dentro do Maven; 
• O Cobertura que gera um relatório mostrando a cobertura de testes no seu projeto; 
• O Jetty que sobe uma instância do Jetty com sua aplicação deployed; 
• O Selenium que sobe uma instância do servidor do Selenium para poder fazer os testes de aceitação do Selenium. 

Enfim, existem vários plugins interessantes e é relativamente fácil achar o plugin que faz o que você precisa. É igualmente fácil, também, fazer um plugin para o Maven, o chamado Mojo. 

Para quem quer se aprofundar no assunto, o curso Maven: gerencie dependências e faça o build de aplicações Java é o ponto de partida mais direto.

Para um contexto mais amplo, as formações Aprofunde em Java com Reflection, Gestão de Memória, Exceções, Threads, Build e JVM e Java e Spring Boot trazem o Maven dentro de projetos Java mais completos e modernos.

Quem quiser uma jornada completa de back-end pode seguir pela carreira de Desenvolvimento Back-End Java. 

FAQ: Perguntas frequêntes sobre Maven Build e mvn compile 

1. O que é o arquivo pom.xml e qual é sua função no Maven?  

O pom.xml é o arquivo central de configuração do Maven, localizado na raiz do projeto. Nele você declara a identidade do projeto (groupId, artifactId e version), suas dependências e configurações de build — sem precisar programar os passos manualmente, como no Ant. 

2. Como o Maven gerencia as dependências do projeto automaticamente?  

Basta declarar a dependência dentro da tag <dependencies> no pom.xml. O Maven baixa o JAR correspondente e todas as suas dependências transitivas do repositório central, adicionando-as automaticamente ao classpath — eliminando a necessidade de baixar e configurar arquivos manualmente. 

3. Como funciona o ciclo de vida do Maven build e quais são suas principais fases?  

O build do Maven segue um ciclo de vida com fases sequenciais: compile → test → package → integration-test → install → deploy. Ao executar mvn package, por exemplo, o Maven processa automaticamente todas as fases anteriores antes de chegar à fase solicitada. 

4. Como usar plugins no Maven e para que servem?  

Plugins estendem as funcionalidades do Maven e são executados com o comando mvn [nomedoplugin]:[target]. Exemplos úteis incluem o Archetype (gera estrutura inicial do projeto), Cobertura (relatórios de cobertura de testes) e Jetty (sobe servidor local). Eles podem ser associados a fases específicas do ciclo de vida. 

5. É possível personalizar a estrutura de diretórios de um projeto Maven?  

Sim. Caso o projeto não siga a estrutura padrão do Maven, você pode configurar caminhos alternativos para código-fonte, testes e recursos dentro da tag <build> no pom.xml, apontando para os diretórios desejados com a propriedade ${project.basedir}.