Ciclo de vida de construcción de Maven en Java

Un ciclo de vida es la idea central de Maven: construir un proyecto no es un conjunto arbitrario de tareas, sino una secuencia ordenada de fases bien definidas. Cuando escribes mvn package, no estás nombrando una acción — le estás pidiendo a Maven que ejecute cada fase hasta package inclusive, en orden. Entender esa secuencia, y cómo los objetivos de los plugins se vinculan a ella, marca la diferencia entre usar comandos a ciegas y saber realmente qué hace tu proceso de construcción.

Tres ciclos de vida, y el que más usarás

Maven incluye tres ciclos de vida integrados. Son independientes — invocar una fase de uno no activa otro.

El ciclo de vida default es donde ocurre el trabajo real. Ese mvn clean install que ves en todas partes es simplemente dos ciclos de vida en un solo comando: la fase clean del ciclo de vida clean, y luego la fase install del ciclo de vida default.

Las fases del ciclo de vida default

El ciclo de vida default tiene 23 fases, pero siete soportan casi toda la carga de cualquier construcción. Siempre se ejecutan en este orden:

La regla que lo rige todo: ejecutar una fase ejecuta esa fase y todas las fases anteriores. Por tanto, mvn package ejecuta silenciosamente validate, compile y test primero. No hay forma de "saltarse" fases — solo puedes detenerte antes.

mvn validate     # just the sanity checks
mvn compile      # validate -> compile
mvn test         # validate -> compile -> test
mvn package      # ... -> test -> package (produces target/app-1.0.jar)
mvn install      # ... -> package -> verify -> install (now in ~/.m2)
mvn deploy       # the full pipeline, ending with an upload

Las fases están vacías hasta que los plugins vinculan objetivos a ellas

Una fase es solo un nombre y una posición en la secuencia — no realiza ningún trabajo por sí misma. El trabajo lo realizan los objetivos de plugins que están vinculados a las fases. Un objetivo se escribe como plugin:goal, por ejemplo compiler:compile. Para un proyecto cuyo <packaging> es jar, Maven proporciona un conjunto de vinculaciones predeterminadas razonables:

Puedes añadir tus propias vinculaciones en pom.xml. Aquí el plugin exec se conecta a la fase verify para que se ejecute automáticamente cerca del final de la construcción:

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <version>3.1.0</version>
      <executions>
        <execution>
          <id>smoke-test</id>
          <phase>verify</phase>
          <goals><goal>java</goal></goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

También puedes invocar un objetivo directamente, fuera de cualquier fase — mvn compiler:compile ejecuta solo ese objetivo, omitiendo el ciclo de vida por completo. Eso es ocasionalmente útil, pero en el día a día llamas a fases y dejas que se disparen las vinculaciones.

Un ejemplo práctico: simulando el ciclo de vida

Maven en sí no está instalado en este entorno de ejecución, así que modelamos el ciclo de vida en Java puro para hacer concretas sus reglas. El programa lista las fases del ciclo de vida default, registra el plugin:goal vinculado a cada una, luego "ejecuta" mvn install — ejecutando cada fase desde validate hasta install, y demostrando que deploy y clean no se incluyen.

Lo que hay que extraer de la ejecución:

• La salida comienza en validate y se detiene en install — seis fases para un solo comando. Esa es la regla acumulativa en acción: mvn install es la abreviatura de ejecutar todo el prefijo de la secuencia hasta install, nunca solo la fase nombrada.
• Cada fase ejecutada imprimió el plugin:goal vinculado a ella (compile -> compiler:compile, package -> jar:jar, etc.). Las fases son ranuras; los objetivos son lo que realmente compila, prueba y empaqueta. validate imprimió (no goal bound), mostrando que una fase puede ejecutarse sin hacer nada.
• deploy skipped : true confirma que las fases posteriores a la que solicitas nunca se ejecutan. Para publicar en un repositorio remoto debes pedir explícitamente mvn deploy; un simple install permanece deliberadamente local.
• clean ran : false demuestra que clean pertenece a un ciclo de vida separado. Invocar install no elimina target/, por eso mvn clean install especifica los dos — una fase de cada ciclo de vida.
• Las fases se ejecutaron en el orden fijo validate, compile, test, package, verify, install y el programa terminó con BUILD SUCCESS. El orden no es negociable; la promesa de convención-sobre-configuración de Maven se basa en esta secuencia garantizada y repetible.

Comandos habituales en la práctica

Un puñado de invocaciones cubre casi todo el trabajo diario:

mvn clean              # delete target/
mvn test               # build and run unit tests
mvn package -DskipTests  # build the JAR without running tests
mvn clean install      # fresh build, install to local ~/.m2
mvn clean verify       # CI's favourite: build + unit + integration checks

-DskipTests compila las pruebas pero no las ejecuta; -Dmaven.test.skip=true omite también su compilación. Recurre al primero cuando las pruebas son lentas pero deben seguir compilando, y al segundo solo cuando realmente quieras que queden fuera por completo.

Qué hacer a continuación

• ¿Eres nuevo en la herramienta? Empieza con la introducción a Maven, luego lee cómo el POM declara plugins y vinculaciones.
• Las fases como compile y package solo tienen éxito una vez que se resuelven las bibliotecas del proyecto — consulta gestión de dependencias.
• ¿Prefieres un modelo de grafo de tareas en lugar de una secuencia de fases fija? Compara con la introducción a Gradle.

Práctica