¿Te lo vas a montar en local o en cada proyecto? 🤔
Hola amante de tener que montarte el entorno en cada proyecto,
Venga así, de golpe:
¿Cuántas veces te has tenido que pegar con la instalación de Maven y su versión cada vez que montabas un proyecto?
Al principio cada vez que entraba en un proyecto le dedicaba un par de horas por lo menos…
Pero… ¿Sabías que hay una forma mejor que te da muchos menos dolores de cabeza?
Vale que sí… que ya tienes Maven instalado en tu máquina, llevas toda la vida montando así tus API con Java + Spring Boot y no quieres cambiar.
Bueno, hoy te voy a dar otra opción, para que ya escojas tú, y veas qué opción te interesa más.
Y por eso hoy te voy a hablar de… 🥁
El Wrapper de maven (mvnw).
Así de golpe no sabrás de qué estoy hablando, por eso vamos con los ejemplos, que es lo que a ti te gusta.
¿Maven local o Maven Wrapper?
Opción A: Maven instalado en tu máquina
Esta es la opción que seguramente tengas y es con la que nos hemos criado (por así decirlo).
Coges, te descargas Maven y te lo instalas en local.
Ventajas ☑️
Ya lo tienes en el PATH y te sabes
mvn clean package
de memoria.Cero ficheros extra en el repo.
Si estás trabajando con 20 APIs entonces a lo mejor si te interesa.
Problemas ❌
Diferencia de versiones: tú con Maven 3.9.X, tu compi con 3.6.X… y en el servidor “en mi local funciona”.
Onboarding lento: cada persona que se incorpora al equipo tiene que instalar Maven y configurar entorno.
CI/CD: tu pipeline debe instalar una versión concreta o “la que haya”.
Opción B: Maven Wrapper (ficheros mvnw
, mvnw.cmd
y carpeta .mvn/
)
Esta es la opción del Wrapper, que resumiendo consiste en tener Maven instalado en el propio proyecto.
Ventajas ☑️
Reproducible: todo el equipo (y CI) usan la misma versión de Maven definida en el repo.
Cero instalaciones previas: solo necesitas Java; el Wrapper descarga Maven la primera vez.
Rápido para los nuevos: clonan y ejecutan
./mvnw spring-boot:run
. Fin.Menos roces en CI: el pipeline llama al Wrapper y usa justo la versión que tú has fijado.
Problemas ❌
Añades unos archivos más al repo (mínimos).
La primera ejecución descarga Maven (unos segundos extra la primera vez).
Entonces… ¿Cuál usaría yo?
Pues en general te recomendaría que para proyectos de equipo y/o con CI, usa el Maven Wrapper.
En local puro y duro para un script rápido te da igual, pero en cuanto trabajas con más gente o automatizas, el Wrapper te ahorra sustos.
Ahora, es posible que ya estés trabajando en un proyecto en donde tenéis 23647 APIs y todas usan la misma versión de Maven, hombre, pues ahí a lo mejor no te diría que hagas el cambio.
Pero a la que haya que montar una nueva API con otra versión de Java o Maven, pues aprovecha.
Pero espera… que el email no acaba aquí, te pensabas que te iba a dejar con la recomendación y ya… eso lo hago en LinkedIn, aquí ya sabes, vamos un pasito más y vamos a generar un Wrapper de nuestro Maven 😘.
(Aunque en la propia página de Spring Boot es fácil descargarse el Wrapper, pero por si tu Maven tiene configuración específica)
¿Cómo añadir (o asegurar) el Maven Wrapper?
Si tu proyecto aún no lo tiene:
mvn -N io.takari:maven:wrapper -Dmaven=3.9.6
Esto genera:
mvnw
(Unix/Mac)mvnw.cmd
(Windows).mvn/wrapper/*
(config del wrapper)
Importante: commitea esos archivos al repositorio.
¿Cómo fijar/actualizar la versión de Maven usada por el Wrapper?
Abre .mvn/wrapper/maven-wrapper.properties
y verás algo como:
distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.6/apache-maven-3.9.6-bin.zip
Cambia el número para subir/bajar versión de Maven (y súbelo al repo).
Todos los que hagan
./mvnw
usarán esa versión automáticamente.
Para regenerarlo con otra versión también puedes:
./mvnw -N io.takari:maven:wrapper -Dmaven=3.9.7
“Pero… es que estoy lanzando
mvn install
y no funciona”
Es que ese es el mvn que tenías instalado en tu máquina, para lanzar los comandos tenemos que ejecutar el maven de nuestro proyecto.
Comandos equivalentes (idénticos, pero con Wrapper)
Construir:
./mvnw clean package
Arrancar Spring Boot:
./mvnw spring-boot:run
Ejecutar tests:
./mvnw test
En Windows: mvnw.cmd …
Buenas prácticas rápidas
Incluye el Wrapper en el repo (sí o sí).
Documenta en el README: “Usa
./mvnw
” en lugar demvn
.En CI/CD, llama al Wrapper:
./mvnw -B clean verify
Si necesitas Java específico, apóyate en Java Toolchains (Maven) o define la versión en tu pipeline. El Wrapper te fija Maven; la JVM va por otro carril.
¿Dockerizas? Genial, pero dentro del contenedor sigue usando
./mvnw
para evitar drift también en la imagen.
Y ahora, como siempre, te toca a ti.
Prueba a montarte el Wrapper de tu proyecto y prueba.
Luego ya me dices si te parece mejor o no.
Mini checklist para dejarlo listo hoy mismo y dejarte de excusas
Generar Wrapper con la versión que quieres usar.
Commit de
mvnw
,mvnw.cmd
y.mvn/
.README actualizado con comandos
./mvnw
.Pipeline (GitHub Actions/GitLab/Jenkins) llamando a
./mvnw
.
Nos leemos dentro de otra semana!