Maven Divide tu código, pruébalo y vencerásWUL4 Trainning Thursday 3Cristian Romero Matesanz

cristianprofile@gmail.com

20-02-2014

Índice 1.Diferencia proyectos antes/después de

usar Maven 2.Importancia de las pruebas en tus

programas 3.Ventajas del uso de Maven 4. Estructura de un proyecto Maven 5. Fases de un proyecto Maven 6.Plugins Maven

Problemática de creación de un proyecto sin Maven

Jar 1Jar 2Jar 3

Jar 200

Controladores

Servicios

Dao

Util’s

5. Papá y ahora como lo probamos?

4. Como metemos una nueva librería?

3. Como modificamos alguna versión de una librería?

2. Por qué cada proyecto tiene distinta estructura?

1. Como me instalo el proyecto?

¿?

¿?

Pocos módulosProyectos grandes

Rest

ws

batch

PROYECTO CON MAVEN

Dao

Service api (Excepciones, interfaz, dto)

Service impl

Controlador aplicación

Servicio Rest

Dao Api (Excepciones Pojos, interfaz)

Core

Core Api (ExcepcionesDtos usados etc..)

Parent Pom (Gestión de versiones de librerías a usar)

Muchos módulos muy pequeños

La importancia de los test

Rápida Repetible

IndependienteProfesional

Automatizable

Test Unitarios Test Integración

Test de carga Test hacking

Pruebas de toda la arquitectura

Códigos poco mantenibles

+ acoplamiento - cohesiónLos errores encontrados fase final- Coste prevención < Coste correctivo (Efecto propagación de errores)- Mantenimientos costosos- Código copy-paste- Uso de librerías sin pruebas

1908 Ford T 2013 Test Dummies

Por qué usar Maven Estandariza la estructura de directorios Gestión de dependencias Estandariza el ciclo de vida Reutilización de módulos Facilita probar tu código de manera unitaria y de

integración: muchos módulos con poco código. Delegar obligaciones. Evitar código Espagueti.

Facilita la integración continua: Jenkins trabaja por ti. Ej: Pruebas de carga (Jmeter ) Pruebas unitarias y de integración con cada cambio en el

repositorio. Calidad del código (Sonnar) Despliegues automáticos.

Se compone de muchos plugins que facilitan las tareas del día a día dentro de tu proyecto

Estructura de un proyecto Maven

src/main/java : clases del modulo creado src/main/resources : aquí almacenaremos los recursos

(ficheros xml, ficheros de propiedades, imágenes, …) que necesita nuestro modulo para funcionar.

src/test/java : clases test para probar las clases de nuestro módulo.

src/test/resources : ficheros de recursos para pruebas. Pom.xml: descripción de nuestro modulo (nombre,

version, dependencias a usar y plugins) Target: carpeta que usa maven para dejar almacenada los

resultados de los comandos.Nota: todo proyecto o modulo maven hereda de un “super pom” donde se define el build por defecto, para que todos los proyectos usen toda la estructura

Pom.xml el corazón de maven

<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"> <groupId>es.wul4.demoapp</groupId> <artifactId>wul4Service</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <name>mi primer modulo maven</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>

Pom.xml el corazón de maven groupId :identificará su proyecto de forma única

(formato de paquetes proyecto java) Una buena idea a la hora de nombrarlo es tener en

cuenta la estructura del proyecto. Si se trata de un proyecto agregaremos al nombre del parde un nuevo id.

org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

artifactId: Es el nombre del jar sin version.maven, commons-math

version identificador de la versión del la libreria(1.0, 1.1, 1.0.1, ...). No usar fechas, seran usadas para las versiones snapshot que tengamos en desarrollo pero no publicadas para su uso.

Packaging: jar, war, ear and pom

compile – es el valor por defecto. Se utiliza en todos los casos (compilar, ejecutar, ...).

provided – también se utiliza en todos los casos, pero se espera que el jar sea suministrado por la JDK o el contenedor. Es decir, no se incluirá al empaquetar el proyecto, ni en el repositorio.

runtime – no se utiliza para compilar, pero si es necesario para ejecutar.

test – Sólo se utiliza para compilar o ejecutar los test. system – es similar a provided, pero eres tu el que

tiene que suministrar el jar. No se incluirá al empaquetar el proyecto, ni en el repositorio.

Pom.xml: dependencias <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency>

Pom.xml el corazón de maven

Permite herencia(podemos heredar de módulos de tipo “pom” ), de modo que heredamos sus valores y podemos sobreescribirlos

<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/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion><parent>

<groupId>com.mylab.learn</groupId><artifactId>mylab-parent-pom</artifactId><version>1.0.0-RELEASE</version>

</parent><groupId>com.mylab.learn.myarchetype</groupId><artifactId>myarchetype-parent-pom</artifactId><version>1.1.0-SNAPSHOT</version><packaging>pom</packaging><name>myarchetype</name><description>my archetype parent pom, restful server and

client</description>https://github.com/butcherless/mylab/tree/master/project-archetype

Pom.xml el corazón de Maven SI el proyecto es de tipo pom definirá:

versiones de propiedades Librerias que se pueden usar si heredan de mi

<dependencyManagement> Plugins se pueden usar si heredan de mi:

<pluginManagement>

https://github.com/butcherless/mylab/blob/master/parent-pom/pom.xml

Al heredar de dicho pom se podrán usar todo lo definido en el fichero, incluso sobrescribir las versiones a usar (no recomendable)

Fases de un proyecto Maven validate: Valida que el proyecto esta correcto y dispone

de la información necesaria. compile: Compila el código fuente del proyecto. test: Prueba el código fuente compilado haciendo uso de

frameworks para pruebas unitarias (JUnit). package: Empaqueta el código fuente compilado (por

ejemplo creando un jar o war). integration-test: Procesa y despliega el paquete dentro

de un entorno de test de integración. verify: Ejecuta los controles necesarios para  verificar si

el paquete es válido y cumple con los criterios de calidad. install: Instala el paquete dentro del repositorio local,

para poder usarlo como dependencia en otro proyecto. deploy: Copia el paquete final al repositorio remoto para

compartir con otros desarrolladores y proyectos.mvn install mvn Package mvn clean install

El repositorio de Maven (Remotos Pom.xml): lugares donde se

conecta para descargar librerías en local necesarias. Por defecto  Maven Central Repository. Si necesitamos alguno adicional

<repositories> <repository> <id>my-internal-site</id> <url>http://myserver/repo</url> </repository> </repositories>

(Local)Lugar donde se almacenan las librerías y las versiones de nuestros módulos. Por defecto <USER_HOME>/.m2/repository pero

se puede modificar

Plugins Maven Componente software que agrega

funcionalidad. En el caso de Maven cada pluging agrega nueva lógica al sistema. Se ejecutan mvn + plugin

mvn clean mvn compile mvn pmd:pmd mvn cobertura:cobertura mvn site:site

https://maven.apache.org/plugins/

Plugins Maven

Plugins Maven

Plugins Maven

PROYECTO CON MAVEN

Dao

Service api (Excepciones, interfaz, dto)

Service impl

Controlador aplicación

Servicio Rest

Dao Api (Excepciones Pojos, interfaz)

Parent Pom (Gestión de versiones de librerías a usar)

Ejemplo práctico

Ejemplo