SalvaAí | Artigos

Bem-vindo ao SalvaAí

Wed, 30 Sep 2026 00:00:00 GMT

O SalvaAí é o meu portal para artigos, manuais e comentários sobre tecnologia e o que mais valer a pena salvar.

O que você vai encontrar

Artigos: textos sobre Java e tecnologia, comentários sobre notícias e opiniões.
Manuais: guias sobre temas específicos, organizados para consultar sempre que precisar.

Quem sou eu?

Sou João Pedro Ramos Campêlo, de Recife. Sou formado em Análise e Desenvolvimento de Sistemas e gosto do ponto em que tecnologia e finanças se encontram.

Passei quatro anos na TOTVS, onde trabalhei com clientes de diversos setores. Foi ali que aprendi a traduzir regra de negócio em solução técnica e a conversar com quem não é da área de tecnologia, e foi ali também que comecei a desenvolver, por iniciativa própria, em ADVPL.

Meu foco de estudo e de construção é backend em Java, com Spring Boot, APIs REST e banco de dados relacional. Fora do trabalho, desenvolvo dois projetos próprios. O Whallet (whallet.com.br) é uma plataforma de gestão financeira para MEIs e pequenas empresas, que já está no ar com usuários acessando. O WhalletRoute é uma plataforma de roteirização e gestão de cargas, ainda em construção.

Também faço pós-graduação em Arquitetura de Sistemas na FIAP, e boa parte dos temas daqui vem dessa rotina.

O SalvaAí nasceu disso. Escrevo para fixar o que estudo e deixo registrado o que pode ajudar quem está no mesmo caminho.

Use a busca (tecla /) ou navegue pelos temas para encontrar o que procura. Para acompanhar as novidades, assine o RSS.

Maven, o nosso orquestrador

Sun, 21 Feb 2021 00:00:00 GMT

Maven: o que é e por que todo desenvolvedor Java deveria conhecê-lo

Provavelmente já encontrou um arquivo chamado pom.xml em algum projeto.

Talvez também tenha visto comandos como:

mvn clean install

ou:

mvn spring-boot:run

Mas afinal, o que é o Maven?

De forma simples, o Apache Maven é uma ferramenta de automação de build e gerenciamento de projetos Java. Ele ajuda a baixar bibliotecas, compilar o código, executar testes, empacotar a aplicação e até publicar artefatos.

Mas essa definição ainda não explica por que ele é tão presente no ecossistema Java.

Para entender isso, precisamos voltar um pouco.

O problema que o Maven resolve

Imagine que você está criando uma API Java.

Seu projeto precisa de:

Spring Boot - Facilita a criação de aplicações independentes;
PostgreSQL - Gerenciamento de banco de dados relacional;
JUnit - Framework padrão para testes unitários em Java;
Mockito - Biblioteca de simulação para Java;
Jackson - Biblioteca Java para processamento de dados JSON;
Hibernate - Framework de mapeamento (ORM) para Java.

Todas essas bibliotecas são arquivos .jar.

Sem uma ferramenta de gerenciamento de dependências, você teria que:

procurar cada biblioteca;
baixar os arquivos .jar;
colocá-los no projeto;
descobrir quais outras bibliotecas elas precisam;
resolver conflitos entre versões;
configurar o classpath;
repetir tudo isso quando alguma biblioteca fosse atualizada.

E aqui aparece um problema ainda maior.

Imagine que o Spring Boot dependa de uma biblioteca A, que depende da biblioteca B, que depende da biblioteca C.

Você realmente quer descobrir e baixar todas essas dependências manualmente?

É justamente nesse tipo de situação que o Maven começa a fazer sentido.

Plus: O que é uma biblioteca (Lib)?

Uma biblioteca, no sentido geral, é uma coleção de classes que fornecem ferramentas para que você, como desenvolvedor, não precise escrever essas ferramentas.

O que é o Maven?

O Apache Maven é uma ferramenta de build para projetos Java.

Segundo a própria documentação do projeto, ele utiliza um Project Object Model (POM) para gerenciar aspectos como compilação, testes e documentação do projeto.

Na prática, o Maven ajuda a padronizar tarefas que aparecem constantemente no desenvolvimento Java:

Código-fonte
    ↓
Compilação
    ↓
Testes
    ↓
Empacotamento
    ↓
Artefato

Por exemplo, uma aplicação pode terminar como:

meu-projeto.jar

O Maven consegue cuidar de grande parte desse processo.

Mas talvez a funcionalidade mais conhecida seja outra:

Gerenciar as dependências do projeto.

O `pom.xml`

Quando você cria um projeto Maven, um dos arquivos mais importantes é:

pom.xml

POM significa:

Project Object Model

Ele é o arquivo central de configuração do Maven.

É nele que podemos definir informações como:

nome do projeto;
versão;
Java utilizado;
dependências;
plugins;
tipo de empacotamento;
configurações de build;
informações do projeto.

Um exemplo simples:

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>br.com.exemplo</groupId>
    <artifactId>minha-api</artifactId>
    <version>1.0.0</version>

</project>

Esse arquivo funciona como uma espécie de contrato do projeto com o Maven.

O Maven lê o pom.xml e, a partir dessas informações, sabe como trabalhar com o projeto.

Entendendo `groupId`, `artifactId` e `version`

Você provavelmente verá esses três elementos em praticamente todo projeto Maven.

<groupId>br.com.exemplo</groupId>
<artifactId>minha-api</artifactId>
<version>1.0.0</version>

Eles identificam o projeto.

`groupId`

Normalmente representa a organização ou grupo responsável pelo projeto.

Por exemplo:

<groupId>com.google.guava</groupId>

ou:

<groupId>br.com.salvaai</groupId>

`artifactId`

É o nome do artefato/projeto.

Por exemplo:

<artifactId>minha-api</artifactId>

`version`

Representa a versão:

<version>1.0.0</version>

Juntos, esses valores formam as chamadas coordenadas Maven de um artefato.

E as dependências?

Agora chegamos a uma das partes mais importantes.

Suponha que nossa aplicação precise do Spring Web.

Em vez de baixar manualmente um .jar, podemos declarar a dependência no pom.xml:

<dependencies>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.5.6</version>
    </dependency>

</dependencies>

A partir disso, o Maven consegue resolver e baixar a dependência necessária.

E existe uma característica extremamente importante:

Dependências transitivas

Imagine:

Minha aplicação
       ↓
Biblioteca A
       ↓
Biblioteca B
       ↓
Biblioteca C

Se a Biblioteca A precisa da Biblioteca B, que por sua vez precisa da Biblioteca C, o Maven consegue resolver essas dependências transitivamente.

Ou seja, você não precisa declarar manualmente cada biblioteca necessária por suas dependências.

É uma das razões pelas quais gerenciar projetos Java grandes seria muito mais trabalhoso sem uma ferramenta como o Maven.

De onde o Maven baixa as bibliotecas?

Você pode imaginar que existe uma enorme biblioteca online contendo milhares de artefatos Java.

Esse papel é desempenhado principalmente pelo Maven Central Repository, um dos principais repositórios públicos de dependências do ecossistema Java.

Quando você adiciona uma dependência ao pom.xml, o Maven procura o artefato nos repositórios configurados e pode armazená-lo no seu repositório local.

Por isso, depois de baixar uma dependência uma vez, ela normalmente não precisa ser baixada novamente para cada projeto.

O fluxo pode ser entendido assim:

pom.xml
   ↓
Maven
   ↓
Repositório remoto
   ↓
Dependência
   ↓
Repositório local
   ↓
Projeto

O repositório local

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

No Linux e macOS, normalmente ele fica em:

~/.m2/repository

No Windows:

C:\Users\SEU_USUARIO\.m2\repository

Imagine que você utilize:

<artifactId>junit-jupiter</artifactId>

Depois que o Maven baixa essa dependência, ela fica disponível no repositório local.

Isso também ajuda a evitar downloads desnecessários.

O ciclo de vida do Maven

Outra ideia fundamental do Maven é o Build Lifecycle.

Em vez de cada projeto inventar seus próprios comandos e etapas de build, o Maven possui ciclos de vida padronizados.

O ciclo default, por exemplo, possui várias fases.

Algumas das mais conhecidas são:

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

Cada fase representa uma etapa do processo de construção do projeto.

Vamos entender algumas delas.

`compile`

Compila o código-fonte.

mvn compile

`test`

Executa os testes.

mvn test

`package`

Empacota a aplicação.

Por exemplo:

target/
└── minha-api-1.0.0.jar

Com:

mvn package

`install`

Além de construir o artefato, instala o resultado no repositório local.

mvn install

`deploy`

Pode publicar o artefato em um repositório remoto configurado.

mvn deploy

Essas fases são executadas em sequência.

Por exemplo, quando você executa:

mvn package

o Maven não executa apenas package.

Ele passa pelas fases anteriores necessárias:

validate
   ↓
compile
   ↓
test
   ↓
package

Isso torna o processo de build previsível e padronizado.

E o famoso `mvn clean install`?

Você provavelmente encontrará esse comando em praticamente qualquer projeto Java baseado em Maven:

mvn clean install

Mas o que ele faz?

Primeiro:

mvn clean

Remove os arquivos gerados pelo build anterior.

Normalmente isso significa remover a pasta:

target/

Depois:

mvn install

Executa o ciclo necessário até instalar o artefato no repositório local.

Simplificando:

clean
  ↓
remove build anterior
  ↓
compile
  ↓
test
  ↓
package
  ↓
install

É uma maneira bastante comum de garantir que o projeto seja reconstruído do zero.

O que é a pasta `target`?

Se você executar:

mvn package

provavelmente verá uma pasta:

target/

Ela contém arquivos gerados pelo Maven durante o processo de build.

Por exemplo:

target/
├── classes/
├── test-classes/
├── surefire-reports/
└── minha-api-1.0.0.jar

Essa pasta normalmente não deve ser versionada no Git.

Por isso, projetos Java geralmente possuem no .gitignore:

target/

Maven e plugins

O Maven não faz tudo sozinho.

Grande parte de sua funcionalidade é fornecida através de plugins.

Por exemplo, existem plugins responsáveis por tarefas como:

compilação;
testes;
empacotamento;
documentação;
análise de dependências;
execução de aplicações.

Isso torna o Maven extensível.

Por exemplo, o processo de compilação pode utilizar o Maven Compiler Plugin.

Já os testes unitários podem ser executados pelo Maven Surefire Plugin.

Na documentação oficial, as fases do lifecycle possuem bindings que associam determinadas fases a goals de plugins.

Maven não é apenas um gerenciador de dependências

É comum alguém dizer:

“Maven é o gerenciador de dependências do Java.”

Não está totalmente errado, mas é uma definição incompleta.

O Maven também é responsável por automatizar o processo de build.

Podemos pensar nele como:

                Maven
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
Dependências    Build      Testes
       │          │          │
       ↓          ↓          ↓
   Bibliotecas  JAR/WAR   JUnit etc.

Ele também possui mecanismos para documentação, publicação de artefatos, projetos multimódulo e gerenciamento de informações do projeto.

Maven x compilador Java

Uma dúvida comum é:

“Mas o Java já não possui um compilador?”

Sim.

O Java possui o javac, responsável por compilar código Java.

Por exemplo:

javac Main.java

O problema é que um projeto real normalmente envolve muito mais coisas.

Você precisa:

organizar o projeto;
encontrar dependências;
configurar o classpath;
compilar dezenas ou centenas de arquivos;
executar testes;
empacotar o resultado;
controlar versões;
eventualmente publicar o artefato.

O Maven automatiza esse conjunto de tarefas.

Em outras palavras:

javac
↓
compila Java

Enquanto:

Maven
↓
organiza e automatiza o processo de build

O Maven inclusive utiliza plugins para realizar determinadas etapas, como a compilação.

A estrutura padrão de um projeto Maven

Outra vantagem do Maven é a padronização.

Um projeto costuma seguir uma estrutura parecida com:

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

Código da aplicação:

src/main/java

Recursos:

src/main/resources

Testes:

src/test/java

Testes e recursos possuem uma estrutura paralela à aplicação.

Isso significa que, ao abrir um projeto Maven novo, você não precisa descobrir do zero onde cada coisa está.

O próprio Maven estabelece convenções para essa estrutura.

Maven e Spring Boot

Se você está estudando Java para desenvolvimento backend, provavelmente encontrará Maven principalmente através do Spring Boot.

Ao criar uma aplicação Spring Boot, é comum receber um pom.xml semelhante a:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.5.6</version>
</parent>

<dependencies>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

</dependencies>

Perceba algo interessante.

Em muitos casos, você nem precisa informar a versão individualmente de cada dependência.

Isso acontece porque o projeto pode utilizar um parent POM ou mecanismos como dependencyManagement para centralizar versões e configurações.

Alguns comandos que você deve conhecer

Se você está começando com Maven, estes comandos já cobrem uma boa parte do seu dia a dia:

Compilar

mvn compile

Executar testes

mvn test

Gerar o artefato

mvn package

Limpar o projeto

mvn clean

Limpar e gerar novamente

mvn clean package

Limpar, testar, empacotar e instalar localmente

mvn clean install

Visualizar a árvore de dependências

mvn dependency:tree

Esse último é especialmente útil quando você começa a enfrentar conflitos de versões entre bibliotecas.

O próprio Maven disponibiliza o dependency:tree para visualizar a árvore de dependências resolvida.

Então, preciso decorar todos esses comandos?

Não.

Mais importante do que decorar comandos é entender o modelo mental do Maven.

Quando você vê:

mvn clean package

deve conseguir interpretar:

“Quero limpar os arquivos gerados anteriormente e executar o processo de build até gerar o pacote.”

Quando vê:

mvn dependency:tree

deve pensar:

“Quero descobrir quais dependências meu projeto está utilizando e de onde elas vieram.”

E quando abre:

pom.xml

deve pensar:

“Aqui está a definição e boa parte da configuração do meu projeto Maven.”

Maven em uma analogia

Imagine que você abriu um restaurante.

Você poderia:

comprar todos os ingredientes manualmente;
procurar fornecedores;
controlar estoque;
calcular o que precisa ser comprado;
preparar os ingredientes;
organizar a cozinha;
preparar os pratos;
limpar tudo no final.

Ou poderia utilizar um sistema que organiza boa parte desse processo.

O Maven é parecido com esse sistema para um projeto Java.

Você declara:

“Meu projeto precisa dessas ferramentas e bibliotecas.”

E o Maven cuida de grande parte da infraestrutura necessária para transformar:

Código-fonte

em:

Aplicação pronta para ser executada/distribuída

Maven é obrigatório para Java?

Não.

Java não depende do Maven para funcionar.

Existem outras alternativas, como o Gradle, além de ferramentas e abordagens diferentes.

O Maven, porém, tornou-se uma ferramenta extremamente difundida no ecossistema Java e aparece em uma enorme quantidade de projetos.

Por isso, para quem está entrando no desenvolvimento Java profissional, entender Maven é muito mais importante do que simplesmente saber executar mvn clean install.

O objetivo é entender o que está acontecendo por trás do comando.

O que você realmente precisa aprender?

Se você está começando agora, não precisa estudar toda a documentação do Maven.

Comece entendendo estes conceitos:

1. O que é o Maven
       ↓
2. O que é o pom.xml
       ↓
3. Dependências
       ↓
4. Dependências transitivas
       ↓
5. Repositório local
       ↓
6. Maven Central
       ↓
7. Build Lifecycle
       ↓
8. Plugins
       ↓
9. Packaging
       ↓
10. dependencyManagement

Depois disso, ferramentas como Spring Boot, Docker e pipelines de CI/CD começam a fazer muito mais sentido, porque você entende onde o Maven se encaixa dentro do processo de desenvolvimento.

Conclusão

O Maven nasceu de uma necessidade bastante prática: padronizar e simplificar o processo de construção de projetos Java. Desde então, tornou-se uma das ferramentas fundamentais do ecossistema.

Ele não serve apenas para baixar bibliotecas.

Ele ajuda a:

gerenciar dependências;
compilar código;
executar testes;
empacotar aplicações;
padronizar a estrutura dos projetos;
gerenciar plugins;
trabalhar com projetos multimódulo;
publicar artefatos.

E talvez a melhor forma de resumir o Maven seja:

Você descreve como seu projeto é organizado e quais são suas necessidades; o Maven automatiza boa parte do trabalho necessário para construir esse projeto.

Se você está seguindo uma trilha de estudos de Java, entender Maven é um daqueles assuntos que parecem simples no começo, mas que vão economizar bastante tempo conforme seus projetos ficam maiores.

Referências

Desmistificando o JVM, JRE e JDK

Mon, 15 Feb 2021 00:00:00 GMT

JVM, JRE e JDK: afinal, qual é a diferença?

Se você está começando a estudar Java, provavelmente já encontrou três siglas que aparecem o tempo todo:

JVM, JRE e JDK.

À primeira vista, elas parecem representar praticamente a mesma coisa. E, para piorar, muitos materiais explicam esses conceitos usando definições bastante técnicas antes mesmo de explicar como eles se relacionam.

Uma forma simples de entender isso é imaginar que estamos falando de uma cozinha.

🍳 Imagine que Java é uma cozinha

Vamos começar pelo conceito mais importante.

Quando escrevemos um programa Java, o código que criamos não é executado diretamente pelo sistema operacional.

Por exemplo, podemos escrever:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

Esse código é transformado pelo compilador em bytecode, normalmente armazenado em um arquivo .class.

É aí que entram JVM, JRE e JDK.

JVM — o cozinheiro

A JVM (Java Virtual Machine) pode ser comparada ao cozinheiro da nossa cozinha.

É ela quem pega o bytecode Java e efetivamente executa o programa.

Quando você executa:

java Main

a JVM entra em ação.

Ela interpreta ou compila o bytecode para instruções que o computador consegue executar, utilizando técnicas como JIT (Just-In-Time compilation) durante a execução.

E aqui está uma das grandes ideias por trás do Java:

O mesmo bytecode pode ser executado em diferentes sistemas operacionais, desde que exista uma JVM adequada para aquele sistema.

Por isso, podemos ter:

             Main.class
                 │
        ┌────────┼────────┐
        ↓        ↓        ↓
      JVM      JVM      JVM
    Windows    Linux    macOS
        │        │        │
        ↓        ↓        ↓
      CPU      CPU      CPU

O bytecode continua sendo o mesmo.

O que muda é a implementação da JVM responsável por conversar com o sistema operacional e o hardware.

É daí que vem a famosa ideia:

“Write once, run anywhere.”

Escreva uma vez, execute em qualquer lugar.

JRE — a cozinha

Agora imagine que o cozinheiro sozinho não consegue fazer muita coisa.

Ele precisa de uma cozinha, utensílios, ingredientes e toda a estrutura necessária para preparar o prato.

Essa é uma boa forma de imaginar o JRE (Java Runtime Environment).

Conceitualmente, o JRE representa o ambiente necessário para executar aplicações Java.

Podemos simplificar assim:

JRE
├── JVM
└── Bibliotecas necessárias para execução

Ou, usando nossa analogia:

JRE = Cozinha + Cozinheiro + Recursos necessários

Se você simplesmente quer executar uma aplicação Java, você não precisa necessariamente de todas as ferramentas utilizadas pelo desenvolvedor para construir aquela aplicação.

É a diferença entre:

“Quero preparar esta receita.”

“Quero criar novas receitas.”

No primeiro caso, precisamos da estrutura necessária para cozinhar.

No segundo, precisamos de ferramentas adicionais.

JDK — a cozinha completa para o desenvolvedor

É aí que entra o JDK (Java Development Kit).

Se o JRE representa o ambiente necessário para executar aplicações Java, o JDK representa o conjunto de ferramentas necessário para desenvolver essas aplicações.

Podemos imaginar:

JDK
├── JRE
│   └── JVM
└── Ferramentas de desenvolvimento

Entre essas ferramentas está o famoso:

javac

O javac é o compilador Java.

Quando fazemos:

javac Main.java

o compilador transforma nosso código-fonte:

Main.java

em bytecode:

Main.class

Depois, podemos executar esse bytecode utilizando a JVM:

java Main

Portanto, o fluxo simplificado seria:

        Desenvolvedor
             │
             ↓
         Main.java
             │
             │ javac
             ↓
         Main.class
             │
             │ JVM
             ↓
        Programa rodando

Então qual é a diferença?

Podemos resumir tudo em uma frase:

JDK desenvolve, JRE fornece o ambiente de execução e JVM executa o bytecode.

Ou, usando nossa analogia:

Conceito	Analogia	Responsabilidade
JVM	👨‍🍳 Cozinheiro	Executa o bytecode
JRE	🍳 Cozinha	Fornece o ambiente necessário para executar Java
JDK	🧰 Cozinha completa	Fornece ferramentas para desenvolver aplicações Java

A relação pode ser visualizada desta maneira:

┌─────────────────────────────────┐
│              JDK                │
│                                 │
│   ┌─────────────────────────┐   │
│   │          JRE            │   │
│   │                         │   │
│   │      ┌───────────┐      │   │
│   │      │    JVM    │      │   │
│   │      └───────────┘      │   │
│   │                         │   │
│   └─────────────────────────┘   │
│                                 │
│  + ferramentas de desenvolvimento│
└─────────────────────────────────┘

Mas existe um detalhe importante

Essa representação é muito útil para entender os conceitos, mas existe uma ressalva importante.

Atualmente, especialmente a partir do Java 11, a ideia de instalar um “JRE separado” não funciona mais da mesma forma que funcionava em versões antigas do Java.

Distribuições modernas do OpenJDK normalmente são distribuídas como JDKs, e ferramentas como jlink podem ser utilizadas para criar runtimes personalizados.

Por isso, hoje é comum um desenvolvedor simplesmente instalar um JDK, como:

OpenJDK
Temurin
Oracle JDK
Amazon Corretto

e utilizar esse ambiente tanto para desenvolver quanto para executar suas aplicações.

Isso não torna o conceito de JRE inútil.

Pelo contrário.

A distinção continua sendo bastante útil para entender o que uma aplicação Java precisa para ser executada e quais componentes fazem parte do ecossistema Java.

E onde entra o Java?

Aqui existe outra confusão bastante comum.

Quando falamos “Java”, podemos estar falando de coisas diferentes:

Java
├── Linguagem Java
├── Plataforma Java
├── JVM
├── Bibliotecas
└── Ferramentas do JDK

A linguagem é aquilo que escrevemos:

System.out.println("Hello World");

O compilador transforma esse código em bytecode.

A JVM executa esse bytecode.

E o JDK fornece as ferramentas necessárias para construir todo esse processo.

Uma analogia completa

Voltando para nossa cozinha, podemos pensar em todo o processo assim:

Você é o desenvolvedor.

Você escreve uma receita:

Main.java

O JDK fornece as ferramentas necessárias para transformar essa receita em algo que possa ser executado.

O JRE representa a estrutura necessária para executar aquilo.

E a JVM é quem efetivamente prepara a receita.

No final:

Você
 │
 │ escreve
 ↓
Java (.java)
 │
 │ JDK / javac
 ↓
Bytecode (.class)
 │
 │ JVM
 ↓
Aplicação executando

Essa separação é uma das características que tornam o ecossistema Java tão interessante.

O programa não precisa ser compilado diretamente para cada sistema operacional.

Ele é compilado para bytecode, e a JVM de cada plataforma fica responsável por executar esse bytecode.

Para guardar

Se você está começando no Java, não precisa decorar dezenas de definições.

Lembre apenas:

JDK → ferramentas para desenvolver

JRE → ambiente para executar

JVM → máquina virtual que executa o bytecode

Ou, na nossa cozinha:

👨‍💻 JDK é o kit do desenvolvedor.

🍳 JRE é o ambiente de execução.

👨‍🍳 JVM é quem executa o programa.

Entendendo essa relação, fica muito mais fácil compreender o restante do ecossistema Java.

SalvaAí | Artigos

Bem-vindo ao SalvaAí

O que você vai encontrar

Quem sou eu?

Maven, o nosso orquestrador

Maven: o que é e por que todo desenvolvedor Java deveria conhecê-lo

O problema que o Maven resolve

Plus: O que é uma biblioteca (Lib)?

O que é o Maven?

O pom.xml

Entendendo groupId, artifactId e version

groupId

artifactId

version

E as dependências?

Dependências transitivas

De onde o Maven baixa as bibliotecas?

O repositório local

O ciclo de vida do Maven

compile

test

package

install

deploy

E o famoso mvn clean install?

O que é a pasta target?

Maven e plugins

Maven não é apenas um gerenciador de dependências

Maven x compilador Java

A estrutura padrão de um projeto Maven

Maven e Spring Boot

Alguns comandos que você deve conhecer

Compilar

Executar testes

Gerar o artefato

Limpar o projeto

Limpar e gerar novamente

Limpar, testar, empacotar e instalar localmente

Visualizar a árvore de dependências

Então, preciso decorar todos esses comandos?

Maven em uma analogia

Maven é obrigatório para Java?

O que você realmente precisa aprender?

Conclusão

Referências

Desmistificando o JVM, JRE e JDK

JVM, JRE e JDK: afinal, qual é a diferença?

🍳 Imagine que Java é uma cozinha

JVM — o cozinheiro

JRE — a cozinha

JDK — a cozinha completa para o desenvolvedor

Então qual é a diferença?

Mas existe um detalhe importante

E onde entra o Java?

Uma analogia completa

Para guardar

O `pom.xml`

Entendendo `groupId`, `artifactId` e `version`

`groupId`

`artifactId`

`version`

`compile`

`test`

`package`

`install`

`deploy`

E o famoso `mvn clean install`?

O que é a pasta `target`?