Introducción a Apache Maven para Java

Maven es la herramienta estándar de automatización de compilación y gestión de dependencias para Java. Convierte un proyecto en una descripción declarativa — qué es, de qué depende, cómo se construye — y luego ejecuta la compilación por ti. En lugar de gestionar manualmente archivos JAR y opciones de javac, declaras tus necesidades en un único archivo y Maven descarga dependencias, compila, prueba y empaqueta tu código a través de un ciclo de vida predecible y reproducible.

El POM: un proyecto como datos

Todo proyecto Maven se describe mediante un pom.xml (Project Object Model). Identifica el proyecto con tres coordenadas — groupId, artifactId y version (juntas forman el "GAV") — y lista las bibliotecas que necesita. El mismo esquema de coordenadas nombra tu proyecto y cada dependencia, que es como Maven localiza los artefactos en un repositorio.

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>shop-app</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>6.1.0</version>
    </dependency>
  </dependencies>
</project>

El elemento <packaging> indica a Maven qué producir (jar, war, pom). El bloque <properties> contiene valores reutilizables — aquí, la versión de Java que el compilador tiene como objetivo. El POM crece para cubrir plugins, perfiles y herencia; el capítulo sobre el POM de Maven desglosa esas partes.

Dependencias y el classpath transitivo

Solo listas tus dependencias directas. Maven lee el POM de cada dependencia y obtiene todo lo que ellas necesitan — las dependencias transitivas — construyendo el classpath completo automáticamente. Declarar spring-web también incluye spring-core sin que tengas que nombrarlo.

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.17.0</version>
</dependency>

Cada dependencia tiene un scope que controla cuándo está en el classpath. El predeterminado, compile, lo hace disponible en todas partes; test lo limita al código de prueba; provided significa que el entorno de ejecución lo suministra. Para conflictos de versiones, exclusiones y dependencyManagement, consulta dependencias de Maven.

Scope	En classpath de compilación	En classpath de prueba	Empaquetado	Uso típico
`compile` (predeterminado)	Sí	Sí	Sí	Bibliotecas normales
`provided`	Sí	Sí	No	Servlet API, suministrada en tiempo de ejecución
`runtime`	No	Sí	Sí	Controladores JDBC
`test`	No	Sí	No	JUnit, Mockito

El ciclo de vida de la compilación

Las compilaciones de Maven recorren una secuencia fija de fases. Las fases clave del ciclo de vida predeterminado son validate, compile, test, package, verify, install y deploy. Ejecutar una fase ejecuta cada fase anterior — mvn package primero valida, compila y prueba, y luego empaqueta. Nunca se llaman las fases fuera de orden.

mvn compile          # compile main sources
mvn test             # compile + run unit tests
mvn package          # compile + test + build the JAR/WAR
mvn install          # package + copy artifact into your local repository
mvn clean package    # delete target/ first, then build fresh

Cada fase está vinculada a uno o más goals proporcionados por plugins (por ejemplo, compiler:compile está vinculado a la fase compile). Los plugins son donde reside el trabajo real; el ciclo de vida solo lo ordena. El capítulo sobre el ciclo de vida de compilación de Maven recorre los tres ciclos de vida integrados y cómo los goals se vinculan a las fases.

Repositorios

Maven obtiene artefactos de los repositorios. Al compilar, busca primero en tu repositorio local (~/.m2/repository), una caché en tu máquina. Si no lo encuentra, lo descarga de un repositorio remoto — por defecto Maven Central — y almacena una copia localmente para que la siguiente compilación sea rápida sin conexión. Los equipos a menudo añaden un repositorio privado para bibliotecas internas.

project pom.xml  →  local repo (~/.m2)  →  remote repo (Maven Central)
                     (cache hit?)            (download + cache)

Un ejemplo ejecutable

El ejecutor de código no tiene Maven en su classpath, por lo que el programa siguiente modela la mecánica central de Maven con código JDK puro: almacena un pequeño POM como un mapa, resuelve el cierre de dependencias transitivas (eliminando artefactos duplicados) y recorre el ciclo de vida de la compilación, deteniéndose en la fase solicitada. Las formas aquí — coordenadas GAV, resolución transitiva, fases ordenadas — son exactamente lo que hace Maven real.

java— editable, runs on the server

import java.util.*;

public class Main {
    // A coordinate triple, exactly like Maven's groupId:artifactId:version.
    record Gav(String groupId, String artifactId, String version) {
        @Override public String toString() {
            return groupId + ":" + artifactId + ":" + version;
        }
        String jar() { return artifactId + "-" + version + ".jar"; }
    }

// The project model: each artifact mapped to the dependencies it declares.
    static final Map<String, List<Gav>> pom = new LinkedHashMap<>();

static void declare(Gav a, Gav... deps) { pom.put(a.toString(), List.of(deps)); }

// Build the transitive closure the way Maven resolves a classpath.
    static void resolve(Gav a, Set<String> seen, List<Gav> out) {
        for (Gav d : pom.getOrDefault(a.toString(), List.of())) {
            if (seen.add(d.toString())) {   // de-dupe: each JAR appears once
                out.add(d);
                resolve(d, seen, out);      // then pull in its own dependencies
            }
        }
    }

public static void main(String[] args) {
        Gav app     = new Gav("com.example", "shop-app", "1.0.0");
        Gav web     = new Gav("org.springframework", "spring-web", "6.1.0");
        Gav core    = new Gav("org.springframework", "spring-core", "6.1.0");
        Gav jackson = new Gav("com.fasterxml.jackson.core", "jackson-databind", "2.17.0");
        Gav annot   = new Gav("com.fasterxml.jackson.core", "jackson-annotations", "2.17.0");

declare(app, web, jackson);   // our project's direct dependencies
        declare(web, core);           // spring-web transitively needs spring-core
        declare(jackson, annot);      // jackson-databind needs jackson-annotations
        declare(core);
        declare(annot);

System.out.println("Project coordinates: " + app);
        System.out.println("Direct dependencies:");
        for (Gav d : pom.get(app.toString())) System.out.println("  - " + d);

List<Gav> classpath = new ArrayList<>();
        resolve(app, new HashSet<>(), classpath);
        System.out.println("Resolved classpath has " + classpath.size() + " JARs:");
        for (Gav g : classpath) System.out.println("  - " + g.jar());

List<String> phases = List.of("validate", "compile", "test", "package", "install");
        String goal = "package";
        System.out.println("Executing: mvn " + goal);
        for (String p : phases) {
            System.out.println("  phase " + p + " -> OK");
            if (p.equals(goal)) break;   // stop once the requested phase is reached
        }
        System.out.println("BUILD SUCCESS");
    }
}

Lo que se puede extraer de la ejecución:

El proyecto y cada dependencia se nombran con la misma triple GAV, por eso Project coordinates: com.example:shop-app:1.0.0 se lee igual que una línea de dependencia.
Solo se declaran dos dependencias, pero el classpath resuelto tiene cuatro JARs — spring-core y jackson-annotations fueron incluidos transitivamente, exactamente como lo hace Maven.
El conjunto seen garantiza que cada artefacto aparezca una sola vez; esta es la deduplicación de Maven que evita que una biblioteca compartida quede en el classpath dos veces.
Executing: mvn package ejecuta validate, compile y test antes de package y luego se detiene — ejecutar una fase siempre ejecuta cada fase anterior en orden.
La compilación se detiene en package y nunca llega a install, reflejando cómo el goal solicitado limita hasta dónde avanza el ciclo de vida.

Cuándo usar Maven

Maven destaca en proyectos Java y JVM convencionales: sus valores predeterminados de "convención sobre configuración" (fuentes en src/main/java, pruebas en src/test/java, salida en target/) significan que un nuevo colaborador puede compilar cualquier proyecto Maven de la misma manera. Su XML declarativo es fácil de leer y comparar, y el soporte de IDE es maduro. La contrapartida es la verbosidad y la flexibilidad limitada para compilaciones inusuales. Donde necesitas compilaciones muy personalizadas y con scripts, Gradle es la alternativa habitual — usa un script de compilación programable en lugar de XML declarativo, pero cubre el mismo terreno: coordenadas GAV, dependencias transitivas y un grafo de tareas (en lugar de fases).

Próximos pasos

POM de Maven — la estructura completa de pom.xml, incluyendo plugins y herencia.
Dependencias de Maven — scopes, exclusiones y resolución de conflictos de versiones en profundidad.
Ciclo de vida de compilación de Maven — cada fase, los tres ciclos de vida y la vinculación de goals.
Introducción a Gradle — la alternativa basada en scripts a Maven.

Práctica

En Maven, ¿qué ocurre cuando ejecutas 'mvn package'?

Maven ejecuta cada fase del ciclo de vida anterior (validate, compile, test) y luego empaqueta el artefactoMaven ejecuta solo la fase package y omite la compilación y las pruebasMaven despliega el artefacto en un repositorio remotoMaven descarga el JDK antes de compilar