El archivo pom.xml

El pom.xml (Project Object Model) es el archivo central de todo proyecto Maven. Es un documento XML que describe el proyecto: su identidad, sus dependencias, sus propiedades y la forma de construirlo.

Todo pom.xml empieza por una raíz <project> con su espacio de nombres, y declara obligatoriamente la versión del modelo:

<?xml version="1.0" encoding="UTF-8"?>
<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
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <!-- El resto de la configuración aquí -->

</project>

<modelVersion>4.0.0</modelVersion> es obligatorio y vale siempre 4.0.0 hoy: es la versión del formato de archivo pom.xml, no la versión de tu proyecto.

Un pom.xml se lee de arriba abajo, por grandes bloques. Esta es la organización típica:

El bloque <packaging> determina el tipo de entregable:

Si omites <packaging>, Maven elige jar por defecto. Una vez más: convención antes que configuración.

🔧 Mini-ejercicio — Escribe la etiqueta <packaging> para producir una aplicación web desplegable en Tomcat.

<packaging>war</packaging>

Todo proyecto Maven se identifica de forma única por tres coordenadas, a menudo abreviadas GAV: GroupId, ArtifactId, Version.

<groupId>com.exemple</groupId>
<artifactId>mon-app</artifactId>
<version>1.0.0</version>

El sufijo -SNAPSHOT merece una atención especial:

# El nombre del artefacto producido combina artifactId + version
# Ej.: mon-app-1.0.0-SNAPSHOT.jar
mvn package

La combinación groupId:artifactId:version es la «dirección postal» de tu proyecto en el ecosistema Maven. Así es como otros proyectos podrán depender de él.

🔧 Mini-ejercicio — Escribe las tres etiquetas GAV para un proyecto com.banque llamado gestion-comptes en versión de desarrollo 1.0.0.

<groupId>com.banque</groupId>
<artifactId>gestion-comptes</artifactId>
<version>1.0.0-SNAPSHOT</version>

El bloque <properties> define variables reutilizables en todo el pom.xml. Ahí se centralizan las versiones y los ajustes para evitar repeticiones.

<properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <junit.version>5.10.2</junit.version>
</properties>

Luego se reutiliza una propiedad con la sintaxis ${nom}:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>${junit.version}</version>   <!-- reutiliza la propiedad -->
    <scope>test</scope>
</dependency>

Propiedades habituales:

Centralizar las versiones en <properties> es una buena práctica: para pasar JUnit de 5.10 a 5.11, modificas un solo lugar en lugar de cada dependencia.

🔧 Mini-ejercicio — Define una propiedad gson.version con valor 2.10.1, luego muestra cómo reutilizarla en una etiqueta <version>.

<properties>
    <gson.version>2.10.1</gson.version>
</properties>
<!-- ... -->
<version>${gson.version}</version>

Un pom.xml puede heredar de otro pom.xml mediante el bloque <parent>. El hijo recupera entonces las propiedades, dependencias y configuraciones del parent. Es el mecanismo que permite factorizar la configuración común a varios módulos.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.2.5</version>
    <relativePath/>   <!-- vacío: buscar el parent en el repositorio -->
</parent>

El uso más conocido es el parent Spring Boot, que fija las versiones de decenas de bibliotecas para que sean compatibles entre sí. Gracias a él, declaras dependencias sin precisar su versión:

<!-- Sin <version>: se hereda del parent -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

El parent Spring Boot actúa como una «lista de la compra validada»: garantiza que todas tus bibliotecas se entienden bien, sin que tengas que elegir cada número de versión a mano.

Aquí va un pom.xml realista que reúne todo lo anterior: coordenadas, propiedades, parent opcional y dependencias.

<?xml version="1.0" encoding="UTF-8"?>
<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
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <!-- Versión del formato de archivo -->
    <modelVersion>4.0.0</modelVersion>

    <!-- Coordenadas GAV: identidad del proyecto -->
    <groupId>com.exemple</groupId>
    <artifactId>mon-app</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <!-- Variables reutilizables -->
    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <junit.version>5.10.2</junit.version>
    </properties>

    <!-- Bibliotecas usadas -->
    <dependencies>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

Se puede mostrar el pom.xml «efectivo» (con toda la herencia resuelta):

# Muestra el pom completo, parent incluido
mvn help:effective-pom

El comando mvn help:effective-pom es valioso para entender lo que Maven «ve» de verdad, incluido todo lo que viene del parent.

🔧 Mini-ejercicio — Escribe el comando que muestra el pom.xml efectivo, con toda la herencia del parent resuelta.

mvn help:effective-pom

Question 1

¿Qué valen las tres coordenadas GAV?

a) Group, Action, Value

b) GroupId, ArtifactId, Version

c) Git, Apache, Version

d) General, Application, Version

Question 2

¿Qué significa el sufijo -SNAPSHOT en una versión?

a) Una versión publicada y fijada

b) Una versión en desarrollo, inestable y actualizada con frecuencia

c) Una captura de pantalla del proyecto

d) Una versión obsoleta

Question 3

¿Para qué sirve el bloque <properties>?

a) Para declarar las dependencias

b) Para definir variables reutilizables (versiones, codificación) con ${...}

c) Para configurar el servidor web

d) Para escribir el código Java

Question 4

¿Cuál es la ventaja de heredar de un <parent> como spring-boot-starter-parent?

a) Elimina la necesidad de código

b) Garantiza versiones de bibliotecas coherentes y reduce la configuración

c) Acelera la red

d) Cifra el pom.xml

Question 5

¿Qué valor toma siempre <modelVersion> hoy?

a) 1.0.0

b) 3.9.6

c) 4.0.0

d) 17

Corrigé

1. b — GAV = groupId, artifactId, version: identidad única del proyecto.
2. b — -SNAPSHOT marca una versión en desarrollo; sin sufijo es una release fijada.
3. b — <properties> centraliza variables reutilizables con ${...}.
4. b — El parent garantiza versiones coherentes y reduce la configuración.
5. c — <modelVersion> vale siempre 4.0.0.

Consigna

Redacta desde cero un pom.xml para un proyecto identificado por com.banque:gestion-comptes:1.0.0-SNAPSHOT, empaquetado en jar, compilado en Java 17 con codificación UTF-8, y que centralice la versión de JUnit en una propiedad. Luego verifícalo.

Corrección — pom.xml esperado

<?xml version="1.0" encoding="UTF-8"?>
<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
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.banque</groupId>
    <artifactId>gestion-comptes</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <junit.version>5.10.2</junit.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

Verificación:

# Verifica que el pom es válido y resoluble
mvn validate

# Muestra el pom efectivo (parent y propiedades resueltos)
mvn help:effective-pom

Resultado esperado:

[INFO] BUILD SUCCESS

Si mvn validate muestra BUILD SUCCESS, tu pom.xml es sintácticamente correcto y todas sus coordenadas están bien formadas. Un error frecuente: olvidar <modelVersion> o cerrar mal una etiqueta XML.

Puntos a recordar

1. El pom.xml es un archivo XML que describe identidad, propiedades, dependencias y build.
2. Las coordenadas GAV (groupId, artifactId, version) identifican el proyecto de forma única.
3. -SNAPSHOT = versión en desarrollo; sin sufijo = versión publicada y fijada.
4. Las <properties> centralizan variables reutilizables mediante ${nom}.
5. La herencia <parent> factoriza la configuración y garantiza versiones coherentes.

A continuación

Lección 03 — Gestión de las dependencias: declarar bibliotecas, entender los alcances, los repositorios y la resolución transitiva.