Introducción a Maven

Maven es una herramienta open source para la gestión del desarrollo de paquetes software. Nace para facilitar la inclusión de librerías de terceros, y unificar en proceso de compilación, prueba y despliegue.

Las tareas más habituales en el ciclo de vida del desarrollo de software estan contempladas como fases de maven:

• Validar que las fuentes del proyecto estan correctas, y que no hay errores en la definición de las dependencias.
• Compilar los fuentes del proyecto.
• Probar el código fuente compilado, y verificar que supera todos los tests.
• Empaquetar el código compilado en un archivo desplegable.
• Verificar los criterios de calidad con respecto al código empaquetado.

Usando un fichero descriptor "pom.xml" podemos gestionar en un único punto gran parte de la configuración para publicar un paquete software.

Artefactos frente a proyectos

En maven se habla del desarrollo de paquetes de software, que se denominan artefactos. Normalmente cuando se empieza con Maven, ambos conceptos suelen mezclarse, pero sus diferencias son evidentes:

• Un artefacto de software es un programa o paquete diseñado para cumplir con una función determinada.
• Un proyecto un esfuerzo coordinado, limitado en el tiempo para crear o mejorar un artefacto de software.

Un sistema operativo es un artefacto software, mientras que la planificación y organización de un equipo de desarrollo durante seis meses para su construcción es un proyecto. Cuando posteriormente se quieran añadir funcionalidades adicionales al sistema operativo, se podrá abrir un nuevo proyecto sobre el mismo artefacto.

Maven añade a cada artefacto software un número de versión para facilitar su identificación, y su evolución. La recomendación habitual es generar un nuevo número de versión cada vez que se completa un proyecto sobre un artefacto, y utilizar versionado semantico para tener el mayro control posible sobre los artefactos.

Gestión de dependencias

Cuando se desarrollan programas complejos, rápidamente aparece la necesidad de importar librerías de terceros que contengan soluciones ya preparadas para partes de los problemas que tenemos. Todo el proceso de desarrollo de software (y el desarrollo científico) se acaba basando en utilizar funciones que otra gente ha validado como base para nuevas funciones que se necesitan.

En la programación utilizar una librería no siempre es algo trivial. Igual que nosotros importamos una librería para aprovechar funciones ya diseñadas, es probable que dicha librería importe otras librerías para hacer lo mismo. Sin embargo a la hora de distribuir las librerías estas lo hacen como archivos empaquetados sin las dependencias; por lo que para poder ejecutar el programa debemos recopilar todos los empaquetados de las librerías que nosotros usamos como los empaquetados que son usados por alguna de las nuestras. Cuando un programa es grande, hay una gran cantidad de dependencias propias y transitivas; y se hace muy complicado controlar cuales debemos importar. Además debemos tener en cuenta que cada librería suelen publicar diferentes versiones, y cuando se toma la decisión de incluir una librería se selecciona una versión concreta, y se hacen pruebas con la misma; de tal manera que hay que controlar la versión de los empaquetados que se recopilan para la publicación final.

Una de las principales utilidades de maven es la declaración de dependencias. En el fichero pom.xml indicaremos las librerias que necesitamos, así como su versión. Maven utiliza una web especial (https://mvnrepository.com/repos/central) como repositorio por defecto. Cuando se declara una dependencia, maven busca el artefacto asociado en dicho repositorio. Dado que la dependencia es tambien un artefacto maven, automáticamente se importaran todas las dependencias transitivas. A parte del repositorio central, en los artefactos podemos indicar los repositorios en los que queremos buscar determinadas depenencias (por ejemplo para dependencias no públicas).

Maven dispone de un repositorio local. Dicho repositorio suele estar ubicado en el directorio .m2 de la carpeta de usuario. El cometido de dicho repositorio local es actuar como cache de las dependencias. Cuando declaramos una dependencia, primero se comprobará si ya existe descargado previamente en el repositorio local.

Tipos de dependencias

Para completar un proyecto sobre un artefacto, no es necesario incluir todas las dependencias en el programa final. Existe diferentes tipos de dependencias, en lo que maven denomia "scope"

• Dependencia de compilación (compile). Es el tipo de dependencia por defecto si no indicamos una específica. Las depenencias se incluiran en el classpath del proyecto, y se exportaran a la hora de generar el paquete software.
• Dependencia del proveedor (provided). La dependencia va a estar disponible en el entorno de ejecución destino; la necesitamos para realizar la compilación de nuestro artefacto; pero no la exportamos con el paquete software, ya que contamos que esté en el contenedor.
• Dependencia de tiempo de ejecución (runtime). En este caso es una dependencia que no se necesita para la compilación del proyecto, pero si para su ejecución. Un ejemplo clásico de estas son las librerías de controladores jdbc, que se suelen cargar por nombre y funcionan a través de interfaces abstractas ajenas a dichos controladores. La dependencia se exportará en el paquete software, pero no se utilizará para la compilación
• Dependencia de pruebas (test). Esta depenencia sólo es necesaria para poder ejecutar el código de pruebas. Estas dependencias no se utilizan para la compilación del código fuente, ni se exportan en el artefacto software. Si el artefacto incluye código de pruebas, estas dependencias se utilizaran para compilar el código de pruebas, y para ejecutarlo.

Plugins para el ciclo de vida

Un tipo de dependencia especial son los plugins. Se publican como artefactos igual que las dependencias genéricas, pero incluyen código ejecutable por maven. Los plugins no se definen en el apartado de dependencias, si no en la descripción de los pasos de construcción del proyecto.

Como comentamos, maven define un ciclo de vida estandarizado para la gestión de proyectos. Dicho ciclo de vida está disponible a través de interfaces Java, que podemos utilizar para construir un plugin. Los plugins definen las fases en las que entran en ejecución, y maven se encarga de ejecutarlos en dichas fases.

Existen infinidad de plugins, y podemos hacer con ellos multitud de cosas:

• Generar código de cliente para servicios de negocios automáticamente en un determinado directorio.
• Activar el uso de un profiler para publicar métricas de ejecución de tests.
• Generar gráficas uml a partir de la estructura del código.
• Consultar con modelos de calidad de software (PMD, Sonar, CPD); generar informes de calidad, e incluso rechazar la construcción final ante fallos graves de calidad...