Enfoque de partida

El Dockerfile con el que hemos trabajado previamente incluye lo mínimo para desplegar el JAR:

1
2
3
4

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/app.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]

Los problemas que presenta son:

• Necesitamos compilar la aplicación fuera del contenedor.
• Dependencias de Maven instaladas en el entorno de desarrollo.
• No es reproducible al 100%.
• El proceso de compilación y despliegue depende de varios pasos manuales.

Para completar el proceso, podríamos incorporar en el mismo contenedor lo necesario para realizar la compilación, pero todas las herramientas necesarias para ello convivirían con la aplicación desplegada en el contenedor de producción.

Qué es un multi-stage build

Un multi-stage build es una técnica de Docker que consiste en usar un contenedor para construir la aplicación y otro distinto, mucho más pequeño, solo para ejecutarla. Así Docker, compila dentro de un contenedor pesado con las dependencias necesarias para ese proceso, descarta todo lo innecesario y se queda con la aplicación final compilada para desplegarla en otro contenedor mucho más ligero.

Esquema del proceso

1. Stage 1 (builder)
   • Tiene Maven
   • Compila el proyecto
   • Genera el JAR
2. Stage 2 (runtime)
   • Solo tiene Java
   • Copia el JAR
   • Ejecuta la app

De esta forma, el contenedor final no contiene Maven, ni código fuente, ni caché.

Nuevo Dockerfile multi-stage

El nuevo Dockerfile completo con las dos etapas quedaría así:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# ---------- STAGE 1: build ----------
FROM maven:3.9.9-eclipse-temurin-21-alpine AS build
WORKDIR /app 
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn clean package -DskipTests

# ---------- STAGE 2: runtime ----------
FROM eclipse-temurin:21-jre-alpine-3.23
WORKDIR /app 
COPY --from=build /app/target/*-SNAPSHOT.jar app.jar
EXPOSE 8080 
ENTRYPOINT ["java","-jar","app.jar"]

Stage 1 - Build con Maven

FROM maven:3.9.9-eclipse-temurin-21-alpine AS build

• Imagen base con Maven + JDK 21.
• AS build: le ponemos nombre a esta fase para poder referenciarla después.

WORKDIR /app

• Establece el directorio de trabajo dentro del contenedor.
• A partir de aquí, todos los comandos se ejecutan desde /app. (equivalente a hacer cd /app)

COPY pom.xml .

• Copia únicamente el pom.xml al contenedor.
• Se hace así para aprovechar la caché de Docker y no tener que descargar dependencias cada vez que cambia el código fuente.

RUN mvn dependency:go-offline

• Descarga todas las dependencias declaradas en el pom.xml.
• Si después cambia el código pero no las dependencias, Docker reutiliza esta capa y el build es mucho más rápido.
• go-offline es un goal del plugin de Maven, indica que se deben descargar todas las dependencias necesarias para que el proyecto pueda compilarse sin conexión a internet. Es útil para mantener las descargas en la caché de Docker.

COPY src ./src

• Copia el código fuente de la aplicación dentro del contenedor.
• Ya tenemos todo lo necesario para compilar.

RUN mvn clean package -DskipTests

• clean elimina compilaciones anteriores.
• package compila y genera el JAR ejecutable.
• -DskipTests evita ejecutar los tests durante la construcción de la imagen. En entornos reales, los tests suelen ejecutarse previamente en un pipeline de integración continua. Separar la fase de validación de la fase de construcción permite builds más rápidos y predecibles.
• Aquí se genera el mismo JAR que antes creábamos en local, pero ahora dentro del contenedor.

Stage 2 - Runtime limpio

Comienza una nueva fase completamente independiente.

FROM eclipse-temurin:21-jre-alpine-3.23

• Imagen ligera con solo el entorno de ejecución Java.
• No incluye Maven ni herramientas de desarrollo.

WORKDIR /app

• De nuevo, definimos el directorio de trabajo.
• Cada FROM reinicia el contexto, por eso hay que volver a declararlo.

COPY --from=build /app/target/*-SNAPSHOT.jar app.jar

• --from=build indica que copiamos desde el stage anterior.
• Copiamos el JAR generado dentro del contenedor de build.

EXPOSE 8080

• Indica que la aplicación escucha en el puerto 8080.
• No abre el puerto, solo lo documenta a nivel de imagen.

ENTRYPOINT ["java","-jar","app.jar"]

• Define el comando que se ejecutará cuando el contenedor arranque.
• Lanza la aplicación Spring Boot.
• Es equivalente a ejecutar java -jar app.jar

Con esto, hemos separado el proceso de construcción del proceso de ejecución. El contenedor ya no depende del entorno del desarrollador, sino de un proceso reproducible y aislado. Igual que separamos responsabilidades en el código, aquí separamos responsabilidades en el contenedor.

Construcción de los contenedores

De forma similar a cómo construíamos la imagen anterior, lanzamos el siguiente comando en consola que, ahora realizará la compilación de la aplicación y generará la imagen para desplegarla (etiquetada como version 2.0).

docker build -t hello-world-api:2.0 .

En este caso el tiempo para finalizar será superior, aunque será más evidente solo en la primera ejecución. Si el proceso finaliza correctamente, tendremos la nueva imagen disponible.

Para desplegar el contenedor con la aplicación, ejecutamos el siguiente comando:

docker run -p 8080:8080 hello-world-api:2.0

De esta forma, tendremos la aplicación compilada y desplegada, sin haber ejecutado Maven en nuestro equipo.

Comparativa con el enfoque anterior

Hemos conseguido desacoplar la compilación del entorno del desarrollador y mover esa responsabilidad al contenedor. Pero además usando multi-stage conseguimos que esa imagen final:

• No incluye herramientas de construcción innecesarias.
• Mantiene una imagen final ligera.
• Evita inflar la imagen con Maven y código fuente.
• Reproducible totalmente en otros entornos.
• Lista para CI/CD.
• Más segura (al incluir solo los elementos mínimos para su ejecución).

Reflexión

Existe una premisa fundamental a la hora de trabajar con contenedores: Una imagen debe contener solo lo necesario para ejecutarse. Nada más. Debido a ello, multi-stage es el planteamiento recomendado en entornos reales, salvo para la construcción de prototipos ultra rápidos.

Por otro lado, desacoplando la compilación del entorno del desarrollador ya no importa que versión de Maven tiene, si está instalado, si otro desarrollador usa otro sistema operativo, si el servidor se actualiza, etc. El contenedor se convierte en el entorno estándar de construcción de la aplicación. Esto es el enfoque DevOps.

Con las pruebas y los tests sucede algo similar. Durante el desarrollo vamos lanzando comprobaciones manuales y, cuando vemos que todo más o menos funciona, lo damos por válido. Puede que incluso documentemos alguna de ellas, pero suele percibirse como otra tarea pesada que no siempre motiva y que intentamos quitarnos de encima cuanto antes.

Sin embargo, al igual que un buen análisis, diseño y planificación nos ahorra tiempo y evita errores a largo plazo, un buen diseño de los casos de prueba y su automatización contribuye a obtener un mejor resultado final. Además, nos garantiza que podremos detectar rápidamente si un nuevo evolutivo introduce errores que no habíamos contemplado.

Testing en Spring Boot

Spring Boot incorpora de serie varias herramientas que facilitan enormemente la implementación de los primeros tests. Entre ellas destacan:

• JUnit 5: es un framework de testing que nos permite definir y ejecutar test en Java mediante anotaciones como @Test.
• Spring Boot Test: conjunto de utilidades que facilita probar aplicaciones Spring cargando el contexto, inyectando dependencias y simulando peticiones HTTP.
• Maven configurado para ejecutar test: Maven ejecuta automáticamente los test durante el ciclo de compilación, fallando el proceso si alguno no pasa y evitando la generación de artefactos incorrectos.

Primer test de Hello World

Para implementar los primeros tests nos vamos a basar en el Hello World que desarrollamos en el artículo anterior y que ya hemos compilado con Maven.

Al crear la estructura básica del proyecto con Spring Initializr e incluir la dependencia Spring Web, ya deberíamos tener en el pom.xml la dependencia spring-boot-starter-webmvc-test, que nos proporciona todo lo necesario para estos primeros tests.

La aplicación arranca

Se trata de un test de contexto, anotado con @SpringBootTest, que ya tendremos creado automáticamente en la estructura del proyecto dentro de la carpeta src/test. En nuestro caso se denomina SpringBootHelloWorldApplicationTests.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.junit.jupiter.api.Test;  
import org.springframework.boot.test.context.SpringBootTest;  
  
@SpringBootTest  
class SpringBootHelloWorldApplicationTests {  
  
    @Test  
    void contextLoads() {  
    }  
  
}

Este test no contiene lógica alguna, pero precisamente ahí reside su valor. Comprueba que el contexto de Spring arranca correctamente y, si falla, indica que existe un problema grave en la configuración de la aplicación.

Testear un endpoint sencillo: Hello World

El siguiente paso es diseñar e implementar un test para nuestro endpoint /hello. Aunque se trata de un endpoint muy sencillo, ya podemos validar tres aspectos básicos:

1. Que el endpoint existe bajo la URL
2. Que responde con código HTTP 200
3. Que devuelve el contenido esperado

El código del test es el siguiente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.junit.jupiter.api.Test;  
import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.boot.test.context.SpringBootTest;  
import org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc;  
import org.springframework.test.web.servlet.MockMvc;  
  
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;  
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;  
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;  
  
@SpringBootTest  
@AutoConfigureMockMvc  
public class HelloControllerTest {  
  
    @Autowired  
    private MockMvc mockMvc;  
  
    @Test  
    void helloEndpointReturnsHelloWorld() throws Exception {  
        mockMvc.perform( get("/hello") )  
                .andExpect( status().isOk() )  
                .andExpect( content().string("Hello World from Spring Boot!") );  
    }  
}

Elementos que se usan en el test

Anotaciones de Spring y JUnit:

• @Autowired: le indica a Spring que inyecte automáticamente una instancia de MockMvc en el test.
• @Test: anotación de JUnit 5 que marca un método como test y permite que el framework lo ejecute durante la fase de testing.
• @AutoConfigureMockMvc: indica a Spring Boot que configure automáticamente MockMvc, permitiéndonos simular peticiones HTTP a los endpoints sin arrancar un servidor real.

Herramientas para simular peticiones HTTP:

• MockMvc: utilidad de Spring para simular llamadas HTTP (GET, POST, etc.) contra los controladores y verificar sus respuestas.
• get(): construye una petición HTTP de tipo GET contra la ruta indicada, en nuestro ejemplo /hello.
• perform(): ejecuta la petición HTTP simulada y definida previamente. Devuelve el resultado para poder hacer comprobaciones sobre la respuesta.

Validación de la respuesta:

• andExpect(): define una expectativa sobre la respuesta obtenida; si no se cumple, el test falla.
• status() e isOk(): comprueban que el código de estado HTTP de la respuesta sea 200 (OK).
• content(): permite validar el contenido del cuerpo de la respuesta.

Ejecutar los test con Maven

Una vez configurados los tests, podemos ejecutarlos desde el propio IDE o, al igual que para la construcción del artefacto, desde la línea de comandos utilizando Maven.

Desde un terminal, situados en la carpeta raíz del proyecto, ejecutamos:

mvn test

Maven compilará el código y lanzará todos los tests definidos en el proyecto, mostrando el resultado en la consola.

Si forzamos un error -por ejemplo, cambiando el texto esperado en el cuerpo de la respuesta- y ejecutamos de nuevo el comando, veremos cómo el test falla. La salida por consola indicará qué test ha fallado, qué se esperaba que ocurriera y cuál ha sido el resultado real, proporcionando información muy útil para entender el problema y corregirlo.

Conclusiones

En este artículo hemos dado el primer paso en la incorporación de tests automatizados a nuestra API Spring Boot. Partiendo de un ejemplo muy sencillo, hemos visto cómo validar que la aplicación arranca correctamente y cómo comprobar el comportamiento de un endpoint HTTP mediante tests automatizados.

Hasta ahora, en la serie hemos creado una API básica, la hemos compilado con Maven y la hemos preparado para su ejecución. Con estos primeros tests añadimos una capa fundamental de seguridad que nos permitirá evolucionar el código con mayor confianza.

En los siguientes artículos iremos ampliando este enfoque, incorporando tests más completos y sentando las bases para su integración en un proceso de integración continua (CI), donde estos tests se ejecutarán automáticamente en cada cambio del código.

En cuanto queremos compartirla, desplegarla en un servidor o moverla entre distintos entornos (desarrollo, pruebas, producción), empiezan a aparecer los problemas clásicos: versiones diferentes de Java, dependencias que no coinciden, configuraciones específicas de la máquina o incluso sistemas operativos diferentes.

Aquí es donde encapsular la aplicación en un contenedor se convierte en el siguiente paso natural.

Qué es un contenedor

Un contenedor nos permite empaquetar la aplicación junto con todo lo que necesita para ejecutarse: la versión de Java, las dependencias y la configuración básica del entorno. El resultado es un paquete autocontenido que se comporta igual en cualquier máquina donde se ejecute.

Docker es una de las herramientas más extendidas para crear, ejecutar y gestionar contenedores de forma sencilla.

Configuración del contenedor

De forma similar al fichero pom.xml de Maven, para configurar un contenedor Docker usaremos un fichero Dockerfile (sin extensión) que se debe ubicar en la misma ruta del proyecto.

Con el siguiente Dockerfile mínimo se está creando de la forma más simple y limpia un contenedor Docker para ejecutar una aplicación Spring Boot:

1
2
3
4
5
6
7
8
9

FROM eclipse-temurin:21-jre-alpine-3.23  
  
WORKDIR /app  
  
COPY target/SpringBootHelloWorld-0.0.1-SNAPSHOT.jar app.jar  
  
EXPOSE 8080  
  
ENTRYPOINT ["java","-jar","app.jar"]

• En primer lugar se indica una imagen base para el contenedor. En este caso se trata de una distribución ligera de Linux con Java 21 (solo el entorno de ejecución), suficiente para ejecutar una aplicación Spring Boot.
• Después se indica el directorio de trabajo dentro del contenedor. A partir de aquí, todos los comandos se ejecutarán desde /app.
• Se copia el JAR generado por Maven desde el equipo anfitrión al contenedor, renombrándolo como app.jar. El nombre del JAR debe coincidir exactamente con el generado.
• Se indica el puerto en el que escucha la aplicación, que en Spring Boot suele ser el 8080 por defecto, pero a nivel informativo, no se abre el puerto.
• Por último, se define el comando que se ejecutará al arrancar el contenedor, lanzando la aplicación Spring Boot.

Construcción de la imagen

El primer paso es construir una imagen Docker a partir de la cual se podrán crear instancias del contenedor y desplegarlas.

Con Docker ejecutándose, y desde la raíz del proyecto, se lanza el siguiente comando:

1

docker build -t hello-world-api:1.0 .

Qué significa:

• -t helloWorld-api:1.0 es el nombre y versión de la imagen.
• . indica que se trabaja en el directorio actual, donde está el Dockerfile sobre el que generar la imagen.

Si todo va bien, podemos listar las imágenes del sistema con el comando docker images.

Ejecutar el contenedor

Para crear y ejecutar un contenedor a partir de la imagen generada, se lanza el siguiente comando:

1

docker run -p 8080:8080 --name hello-world-api-container hello-world-api:1.0

Qué significa:

• -p 8080:8080 indica el puerto del equipo donde se quieren recibir las peticiones del contenedor, seguido del puerto del contenedor a donde deben dirigirse. En este caso, usa el mismo.
• --name helloWorld-api-container indica un nombre para identificar al contenedor.

De nuevo, si todo va bien, podremos abrir un navegador y acceder a la url http://localhost:8080 y ver el mensaje de ‘Hello World’, esta vez lanzado desde la API en el contenedor.

Para parar el contenedor, que se habrá quedado en la terminal, pulsamos la combinación de teclas Ctrl + C.

Otros comandos útiles

Ejecución del contenedor en segundo plano

Para no tener que mantener la ventana de terminal con el contenedor en ejecución, se puede lanzar en segundo plano añadiendo -d al comando run de la siguiente manera:

1

docker run -d -p 8080:8080 --name helloWorld-api-container helloWorld-api:1.0

Ver logs del contenedor

Para consultar los logs en la consola de Spring Boot dentro del contenedor, lanzamos el siguiente comando:

1

docker logs helloWorld-api-container

Detener el contenedor

Al no estar ahora ligada la ejecución del contenedor a la sesión de terminal, para detenerlo, se debe lanzar el siguiente comando:

1

docker stop helloWorld-api-container

Conclusiones

Ya hemos dado un paso clave: llevar nuestra aplicación Spring Boot desde un simple JAR hasta un contenedor ejecutable, garantizando que se comporta igual independientemente del entorno donde se despliegue.

El flujo que hemos seguido hasta ahora es muy sencillo, pero extremadamente importante:

• Hemos desarrollado una API sencilla en Spring Boot
• Con Apache Maven hemos generado un artefacto ejecutable (el JAR)
• Ese JAR lo hemos encapsulado en un contenedor usando Docker, resolviendo de un plumazo los problemas de dependencias, versiones y entornos.
• Hemos visto que desplegar la aplicación se reduce a construir una imagen y arrancar un contenedor.

A partir de aquí, se abre un abanico de mejoras naturales como optimizar el proceso, orquestar varios servicios y llegar a automatizar todo el flujo de construcción y despliegue. Todo ello de forma cercana a un entorno real de producción.

Docker permite crear y ejecutar aplicaciones dentro de contenedores, facilitando un entorno consistente y reproducible tanto en desarrollo y despliegue. Esto evita el clásico “en mi máquina funciona” y lo convierte en una herramienta clave en flujos modernos de CI/CD.

Instalación de Docker en Windows

En Windows, la forma recomendada de trabajar con Docker es mediante Docker Desktop, ya que su instalación es muy sencilla e incluye todo lo necesario para empezar.

Requisitos previos

En la actualidad, para poder instalar Docker en Windows, el sistema debe cumplir los siguientes requisitos:

• Contar con Windows 10 u 11 de 64 bits (Home o Pro)
• Tener habilitada la virtualización en la BIOS
• Tener activo WSL 2 (Windows Subsystem for Linux)

Virtualización habilitada

Para poder ejecutar Docker y contenedores en un equipo, no solo debe contar con un procesador que lo soporte, también debe tener habilitada la opción de virtualización en la BIOS.

Para verificarlo, se puede acudir al Administrador de tareas de Windows, sección CPU, donde en la parte inferior aparece una etiqueta que indica si la virtualización está habilitada.

Si la configuración indica que está deshabilitada, se debe cambiar desde la BIOS del propio equipo siguiendo las indicaciones específicas del fabricante.

Instalación de WSL 2

WSL (Windows Subsystem for Linux) permite ejecutar un entorno Linux directamente en Windows. Su versión más moderna, WSL 2, ofrece mejor rendimiento y compatibilidad, y es la opción recomendada para trabajar con Docker. Docker Desktop utiliza WSL 2 como backend para ejecutar los contenedores Linux de forma eficiente dentro de Windows.

La instalación es muy sencilla, solo habrá que lanzar el comando siguiente en una terminal.

1

wsl --install

Esto, automáticamente:

• Habilita las características necesarias de Windows.
• Instala WSL 2 (la versión recomendada).
• Descarga e instala Ubuntu como distribución por defecto.

Tras un reinicio, nos pedirá crear un usuario de Linux con una contraseña (no es necesario que coincida con los de Windows.)

Para usar Linux desde Windows, basta con abrir una terminal y lanzar el siguiente comando.

1

wsl

Descarga e instalación de Docker Desktop

Docker Desktop para Windows está disponible para su descarga desde la web oficial de Docker. Ahí está disponible un instalador ejecutable.

Una vez descargado, basta con ejecutarlo siguiendo los pasos marcados, y marcando la opción de “Use WSL 2 instead of Hyper-V” cuando nos lo solicite.

Al finalizar, es posible que sea necesario reiniciar el equipo. Tras ello, ejecutamos Docker Desktop desde el menú Inicio. La primera vez puede tardar unos minutos mientras se configuran los componentes necesarios, llegando a una pantalla similar a la siguiente si todo ha ido bien.

También se puede verificar que todo está funcionando desde la terminal, lanzado el siguiente comando que mostrará la versión en ejecución.

1

docker --version

Opcionalmente, se puede lanzar un contenedor de prueba que mostrará un mensaje de bienvenida con el siguiente comando.

1

docker run hello-world

Conclusión

Con Docker Desktop instalado en Windows ya tenemos un entorno preparado para trabajar con contenedores de forma local. A partir de ahí ya se pueden crear y ejecutar contenedores e integrar Docker en proyectos de desarrollo. Las posibilidades son infinitas y con cierta complejidad si queremos especializarnos, pero la potencia que ofrecen los contenedores, aun con configuraciones básicas, ya son muy grandes.

Objetivo

Se trata de compilar y desplegar una aplicación Spring Boot con Maven utilizando los comandos correspondientes a Maven y Java.

Prerrequisitos

1. Tener instalado y configurado Java. Para comprobarlo, lanzamos el siguiente comando en una terminal:

1

java -version

Que debe devolver una salida similar a la siguiente:

1
2
3

openjdk version "25.0.1" 2025-10-21 LTS
OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.1+8 (build 25.0.1+8-LTS, mixed mode, sharing)

2. Tener instalado y configurado Maven. Para ello, se puede seguir el siguiente artículo: Pasos para instalar Maven en Windows

3. Tener una aplicación Java que haga uso de Maven. Se puede usar la desarrollada en el siguiente artículo: Spring Boot Hello World

Compilar el proyecto

1. Navegar hasta la ruta del proyecto donde está el fichero pom.xml

1

cd ruta/a/tu/proyecto

2. Limpiar y empaquetar usando el comando mvn

1

mvn clean package

• clean → borra compilaciones previas
• package → compila + ejecuta tests + genera el JAR

Si todo va bien, la consola mostrará un mensaje de ‘BUILD SUCCESS’.

Localización del artefacto

Si la compilación ha finalizado correctamente, se habrá generado el fichero jar dentro de la carpeta target dentro de la estructura de carpetas del proyecto. Pero en el caso de una aplicación Spring Boot, nos encontraremos con dos ficheros, un .jar y adicionalmente un .jar.original.

El .jar es el que debemos usar para desplegar, ya que contiene:

• El código de la aplicación compilado
• TODAS las dependencias
• El cargador de Spring Boot
• Un Main-Class ejecutable

El .jar.original por contra, no se usa para desplegar, ya que:

• Es el JAR “normal” de Maven
• Solo contiene el código compilado
• No incluye dependencias
• No es ejecutable

Lo que ha sucedido es Maven ha creado inicialmente el jar estándar SpringBootHelloWorld-0.0.1-SNAPSHOT.jar. Posteriormente, el plugin de Spring Boot lo renombra a SpringBootHelloWorld-0.0.1-SNAPSHOT.jar.original dejándolo como respaldo interno del proceso y realiza un reempaquetado generando el .jar que contiene todo lo necesario para que sea ejecutable.

Despliegue de la aplicación

Una vez localizado el fichero .jar se ejecuta mediante el comando java de la siguiente manera:

1

java -jar target/SpringBootHelloWorld-0.0.1-SNAPSHOT.jar

Mostrando la consola algo similar a lo que se ve en la siguiente imagen.

Y en este caso, se podrá probar que la aplicación funciona accediendo a un navegador.

Conclusiones

Este enfoque permite comprender mejor el ciclo de construcción de una aplicación Java, identificar el artefacto correcto para su despliegue y ganar autonomía a la hora de ejecutar la aplicación en otros entornos.

Entender qué genera Maven y cómo Spring Boot reempaqueta el artefacto final es un paso fundamental antes de abordar escenarios más avanzados como el despliegue en contenedores Docker o en servidores de producción.

Objetivo

Para ejemplificar esta simplicidad, se desarrolla un servicio web con un solo endpoint que devuelva un mensaje de Hello World.

Creación del proyecto base

El ecosistema Spring cuenta con una herramienta que facilita la creación de la estructura base del proyecto, se trata de Spring initializr.

Ésta genera la estructura básica de un proyecto Spring Boot en segundos. Permite seleccionar la versión de Spring, el lenguaje, el build system (Maven o Gradle) y las dependencias necesarias, creando automáticamente un proyecto listo para abrir en cualquier IDE.

Para el Hello World solo es necesario incluir la dependencia de Spring Web.

Al pulsar en GENERATE se descarga un fichero comprimido con el proyecto que cuenta con la estructura y componentes mínimos para importar en cualquier IDE y desplegar la aplicación.

Este proyecto se puede importar o abrir desde cualquier IDE que cuente con soporte para desarrollo de aplicaciones Spring Boot. Para el ejemplo, se utiliza IntelliJ.

Creación del controlador

Un controlador en Spring es el componente encargado de recibir las peticiones HTTP, procesarlas y devolver una respuesta. Actúa como punto de entrada de la aplicación, mapeando URLs y métodos HTTP (GET, POST, etc.) a métodos Java. Separa la lógica de exposición de la API del resto de la aplicación y su lógica, que se conformará con otro tipo de componentes que se utilizarán para obtener respuestas más complejas.

Anotaciones RestController y GetMapping

Las anotaciones en Spring son etiquetas que se colocan sobre clases y métodos para decirle al framework qué papel cumple cada uno y cómo deben actuar, sin necesidad de escribir código adicional de configuración.

RestController

Es la anotación que marca una clase como un componente que expone endpoints REST. Todo lo que devuelvan sus métodos será serializado automáticamente (Strings, JSONs, etc.).

GetMapping

Asocia un método a una petición HTTP GET y a una ruta concreta que se debe especificar como un parámetro de la propia anotación.

Ejemplo completo

Para disponer de un endpoint bajo la ruta /hello que responda a una petición GET, bastaría con completar el Controlador HelloController de la siguiente forma:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

package dev.juanfbermejo.SpringBootHelloWorld;  
  
import org.springframework.web.bind.annotation.GetMapping;  
import org.springframework.web.bind.annotation.RestController;  
  
@RestController  
public class HelloController {  
  
    @GetMapping("/hello")  
    public String hello() {  
        return "Hello World from Spring Boot!";  
    }  
  
}

Prueba de la aplicación

Para probar la aplicación y ver el HelloWorld bastaría con ejecutar en nuestro IDE la clase anotada con SpringBootApplication.

En la consola veremos aparecer varios logs que nos indicarán:

• Inicialización del servidor web (Tomcat por defecto) y el puerto en el que estará escuchando para recibir las peticiones (8080 por defecto)
• Inicialización correcta de la propia aplicación.

En ese momento, podremos abrir un navegador web e intentar cargar la url http://localhost:8080/hello lo cual realiza por defecto una petición GET a la ruta, devolviendo en la pantalla el texto de HelloWorld.

Conclusiones

Montar un Hello World en Spring Boot es rápido y sencillo, y un buen punto de partida para entender las piezas que lo hacen posible. Las anotaciones son uno de los pilares del framework, y dominar su significado permite construir aplicaciones más limpias, expresivas y mantenibles.

Apache Maven es una herramienta de gestión y automatización de proyectos Java. Su objetivo principal es simplificar ciertas tareas de desarrollo como la compilación, la gestión de dependencias, ejecución de test y generación de artefactos (como pueden ser los archivos JAR).

La configuración del proyecto se centraliza en el fichero pom.xml (Project Object Model) a partir de la cual, Maven se encarga de descargar librerías y ejecutar las tareas correspondientes.

Maven se ha convertido en una herramienta esencial en el desarrollo de aplicaciones Java.

Instalación de Maven en Windows

Aunque Windows quizás no es el mejor sistema para utilizarlo en desarrollo de software, y la instalación de algunas herramientas implica cierta dificultad, en el caso de Maven basta con seguir un poco pasos para tenerlo funcionando.

Comprobación previa a la instalación

En primer lugar, se puede verificar si el equipo ya cuenta con una instalación de Maven correctamente configurada. Para ello, basta con abrir una consola de terminal y ejecutar el siguiente comando:

1

mvn -version

Si no está instalado o configurado, obtendremos un mensaje que nos avisa de que el sistema no reconoce el comando:

Descarga de Maven

Desde la web https://maven.apache.org/download.cgi descargamos un ‘Binary zip archive’, que es un fichero zip que contiene lo necesario para ejecutar Maven.

Lo descomprimimos en una ruta de nuestro equipo donde queramos dejarlo instalado. Por ejemplo en C:\user\jfber\Maven\apache-maven-3.9.12

Configuración de sistema

Ahora hay que configurar el sistema para que sepa donde localizar el ejecutable de Maven y que se pueda invocar desde cualquier ruta del sistema.

En primer lugar, hay que configurar una variable de entorno llamada MAVEN_HOME cuyo valor será la ruta completa de la carpeta de Maven creada en el paso anterior.

En el sistema Windows, en Panel de control → Sistema → Editar las variables de entorno del Sistema se crea la nueva variable:

Una vez configurada la variable que almacena la ruta donde se encuentra instalado Maven, se incluye la ruta del ejecutable en la variable Path de forma que se pueda ejecutar Maven desde cualquier ubicación del sistema.

En la variable Path se incluye el siguiente valor, que hace uso de la variable declarada anteriormente:

1

%MAVEN_HOME%\bin

Comprobación de la instalación

Una vez completada la configuración, se debe reiniciar la terminal y se vuelve a lanzar el comando:

1

mvn -version

Si todo está correcto, ahora muestra la información sobre la versión de Maven instalada y el sistema está listo para comenzar a usar la herramienta.