Automatización y administración de dependencias Java con Maven

Por César Hernández
Publicado en Abril 2015

Maven es una poderosa herramienta para proyectos Java que facilita la administración de dependencias promoviendo el principio de integración continua sobre la automatización de la construcción y empaquetado de aplicaciones.

Administrando las dependencias

A medida de que las aplicaciones que desarrollamos en Java requieren de API’s que extienden la funcionalidad base del lenguaje, nos vemos en la necesidad de importar bibliotecas (comúnmente en forma de archivos con extensión .jar) desarrolladas por terceros. Es en este punto en que nuestra aplicación empieza a tener dependencias.

El proceso de agregar, actualizar, eliminar y distribuir dichas dependencias entre un equipo de desarrollo es complejo y altamente propenso a errores. Un primer enfoque que se puede pensar para disminuir la complejidad es versionar dichas dependencias en un repositorio como por ejemplo SVN o GIT. Sin embargo ese enfoque es práctico para el código fuente pero no para las dependencias dado que su naturaleza requiere de  manipulaciones adicionales, como por ejemplo la resolución de dependencias transitivas que pueden ocasionarse cuando una dependencia que importamos a nuestro proyecto a su vez necesita de otra(s) biblioteca(s).

A través de la estandarización, automatización y siguiendo el principio de convención sobre configuración, maven provee mecanismos que nos ayudan a resolver de forma automática los conflictos que surgen cuando existen dependencias transitivas que poseen diferentes números de versiones.

Estandarizando los proyectos basados en maven

Maven se basa en el concepto de Modelo de Objetos de Proyecto (POM) el cual permite que dichos objetos (dependencias, meta data del proyecto y plugins)  puedan ser explícitamente declarados para estandarizar la construcción y empaquetado de  proyectos Java que en conjunto forman una aplicación o sistema.  El archivo de configuración que maven utiliza para este propósito es llamado pom.xml.

Estructura básica de un archivo pom.xml para efectos prácticos la podemos dividir en tres partes:

1. Información general de nuestro proyecto
Contiene la información que hace único al artefacto que el proyecto genera, la información necesaria es:
groupId            Identificación del grupo al que pertenece el proyecto.
id                       Nombre de nuestro proyecto.
packaging       Tipo de empaquetado (por ejemplo jar o war).

2. Sección de dependencias
Contiene la lista de dependencias que el proyecto utilizará. En este punto podemos incluso indicar el scope (ámbito) de cada dependencia, por ejemplo indicar que la dependencia Junit no forme parte del empaquetado final de nuestro proyecto pero que sí esté presente durante la fase de la ejecución de pruebas unitarias.

3. Sección de plugins
Contiene los plugins que extienden las funcionalidades básicas de maven. Esta característica ha hecho muy popular a maven dado que oficialmente da soporta a más de 50 plugins y la lista de desarrollados por terceros es amplia. Existen plugins para empaquetado, generación de reportes, análisis estático de código etcétera.

Instalación:

Se debe de descargar del sitio http://maven.apache.org/download.cgi el empaquetado: apache-maven-3.2.5-bin.zip. Se debe de descomprimir y agregar una variable de entorno a nuestro sistema operativo apuntando a la carpeta bin de la estructura de folders descomprimidos.
Para verificar nuesra instalación basta con ejecutar en una consola el siguiente comando:

mvn –version
La ejecución éxitos muestra el siguiente mensaje:

Java con Maven


Sintáxis de comandos maven:


mvn [opciones] [<goa(s)>] [<fase(s)>]

mvn es el comando que ejecuta maven, un goal representa un plugin de maven que puede ser añadido a una fase para poder especificar o extender el comportamiento de dicha fase y una fase específica que será ejecutada en la construcción de nuestro proyecto.

Creando un proyecto Java con maven:

Para crear un proyecto java con maven, debemos de indicarle el tipo de acción que queremos ejecutar (goal), identificar nuestro proyecto unívocamente (groupId y artifacId), así como seleccionar la plantilla inicial que queremos que nuestro proyecto tenga (archetypeArtifacId). Para efectos prácticos desactivaremos la interacción por consola que maven tiene para consultarnos información adicional (interactiveMode).

mvn archetype:generate -DgroupId=com.miorganizacion  -DartifactId=mi-aplicacion1 
-DarchetypeArtifacId=maven-archetype-quickstart  -DinteractiveMode=false 


La estructura estándar que maven provee para los proyectos es la siguiente:

Java con Maven

Dentro de la estructura creada podemos ver que maven creó por nosotros tanto clases como paquetes y el archivo pom.xml.

Archivo pom.xml generado:

<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/maven-v4_0_0.xsd"> 
<modelVersion>4.0.0</modelVersion> 
<groupId>com.miorganizacion</groupId> 
<artifactId>mi-aplicacion</artifactId> 
<packaging>jar</packaging> 
<version>1.0-SNAPSHOT</version> 
<name>mi-aplicacion</name> 
<url>http://maven.apache.org</url> 
<dependencies> 
<dependency> 
<groupId>junit</groupId> 
<artifactId>junit</artifactId> 
<version>3.8.1</version> 
<scope>test</scope> 
</dependency> 
</dependencies> 
</project> 


Vemos dentro del pom que al nombre de nuestro proyecto se ha agregado automáticamente la versión 1.0-SNAPSHOT, el término snapshot se utiliza para denotar que nuestro proyecto se encuentra en fase de desarrollo sujeto a cambios constantes. Es una buena práctica que luego de la fase de desarrollo nuestros proyectos de maven sean actualizados a una versión puntual que no incluya la palabra SNAPSHOT. Este último cambio se realiza editando el archivo pom.xml. No está demás indicar que el empaquetado de este proyecto será un artefacto jar. 

Automatizando las fases de un proyecto basado en maven:

Maven utiliza un ciclo de vida de construcción para automatizar varias fases de nuestro proyecto: Compilación, Pruebas Unitarias, Empaquetado, Pruebas de integración, verificaciones adicionales y distribución del empaquetado resultante hacia un repositorio maven local y/o centralizado.  Cuando instalamos maven se crea automáticamente el Repositorio Local, mismo que servirá como un punto de cache entre los servidores Maven de internet y nuestra estación de trabajo.

Estando dentro del directorio mi-aplicación podemos ejecutar varias fases sobre nuestro proyecto de manera independiente.

mvn compile
Compila nuestro proyecto y crea un nuevo directorio llamado target en donde almacena nuestras clases compiladas. Es importante remarcar que en esta fase aún no se lleva a cabo la fase de empaquetamiento del jar.

La estructura generada:

Java con Maven

mvn test
Realiza primero la fase de compilación de forma automática y posteriormente ejecuta la fase de pruebas unitarias que el proyecto tenga.

Java con Maven

mvn package
Compila, ejecuta la fase de pruebas y posteriormente empaqueta el proyecto en un archivo .jar. Hasta este punto nuestro .jar se encuentra dentro del folder target.

Java con Maven

mvn install
Compila, realiza la fase de pruebas, empaqueta e instala en nuestro repositorio local de maven el proyecto.

Java con Maven

Vemos en la imagen anterior que el repositorio local llamado .m2/repository ha sido modificado para agregar una copia del artefacto jar generado.

Integración de Maven con IDE’s:

Actualmente maven tiene una amplia integración con los IDE’s más populares para desarrollo Java. Sin embargo el alcance del presente artículo es proveer al lector la información fundamental de las funcionalidades claves de maven con el objetivo de ver el panorama base del software.

Repositorio Oracle Maven:

Recientemente Oracle ha publicado el Oracle Maven Repository lo cual pone a disposición de todos nosotros una serie de dependencias y plugins que facilitará aún más el desarrollo de proyectos Java en sus diferentes ámbitos (JavaME, JavaSE, JavaEE y JavaFx).

Siguientes pasos:

En el siguiente artículo utilizaremos Maven y el Repositorio Oracle Maven para crear aplicaciones totalmente funcionales de una forma estandarizada, automatizada y preparadas para ser posteriormente desplegadas en el servidor WebLogic de manera rápida y sencilla.

Conclusión:

Hemos visto como Maven nos permite optimizar el tiempo de desarrollo de sistemas compuestos de proyectos Java a la vez que obtenemos una estandarización de nuestra forma de trabajo  y automatizamos varias fases en la construcción, validación, empaquetado y distribución de dichos proyectos.

Bibliografías recomendadas:


https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_and_the_oracle

https://docs.oracle.com/middleware/1212/core/MAVEN/toc.htm

http://docs.oracle.com/middleware/1213/core/MAVEN/config_maven_repo.htm#MAVEN9010



César Hernández es Arquitecto de Software que ha trabajado con tecnologías Java Enterprise por más de 7 años en diferentes sectores comerciales y gubernamentales. Oracle Certified Profesional, revisor técnico de Manning Publications Co. TATA TCS Solution Architect y parte del comité organizador de la comunidad de usuarios Java de Guatemala –GuateJUG-, la comunidad Java más grande de Centroamérica.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.