Divide tu código, pruébalo y vencerás. Importancia de uso de Maven, necesidad de códigos probados. Metodología de trabajo TDD.

1. Maven
Divide tu código,
pruébalo y
vencerás
WUL4 Trainning Thursday 3
Cristian Romero Matesanz
cristianprofile@gmail.com
20-02-2014

2. Í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

3. Problemática de creación de un
Pocos módulos
proyecto sin Maven
Proyectos grandes
5. Papá y ahora como
lo probamos?
4. Como metemos
una nueva
librería?
Controladores
Rest
3. Como modificamos
alguna versión de una
librería?
2. Por qué cada
proyecto tiene distinta
estructura?
1. Como me instalo
el proyecto?
Servicios
Util’s
ws
¿?
¿?
Dao
batch
Jar 1
Jar 2
Jar 3
Jar 200

4. Muchos módulos muy pequeños
PROYECTO CON
MAVEN
Core Api (Excepciones
Dtos usados etc..)
Dao Api (Excepciones
Pojos, interfaz)
Dao
Service api (Excepciones,
interfaz, dto)
Core
Service impl
Controlador
aplicación
Servicio Rest
Parent Pom (Gestión de versiones de librerías a usar)

5. La importancia de los test
1908 Ford T
Pruebas de toda la arquitectura
Códigos poco mantenibles
+ acoplamiento - cohesión
Los 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
2013 Test Dummies
Automatizable
Rápida
Repetible
Profesional
Independiente
Test Unitarios
Test Integración
Test de carga
Test hacking

6. 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

7. 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

8. 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>

9. 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.apac he.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

10. Pom.xml: dependencias
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>





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.

11. 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


12. 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)

13. 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

14. 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

15. 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/

16. Plugins Maven

17. Plugins Maven

18. Plugins Maven

19. Ejemplo práctico
PROYECTO CON
MAVEN
Dao Api (Excepciones
Pojos, interfaz)
Dao
Service api (Excepciones,
interfaz, dto)
Service impl
Controlador
aplicación
Servicio Rest
Parent Pom (Gestión de versiones de librerías a usar)

20. Ejemplo