Apuntes Maven

 

el group id = dominio empresa alreves

dependencias trancitivas= el pom puede tener dependencias ocultas, ya que se heredan de las dependencias que estan incluidas en nuestro pom. por ejemplo podemos depender de A y esta a la vez de B y C, de esta forma dependemos de A,B y C, y podemos utilizar herramientas de estas. 

De esta manera tenemos dependecias que dependen de otras y de manera automatica se referencian, y no tenemos que estar preocupados de instanciarlas antes o despues de otra que la requiera, esto lo realiza de manera automática.

limpiar e instalar  librerías y saltarse los test: mvn clean install -Dmaven.test.skip=true

Ver arbol de dependencias: mvn dependency:tree

en la imagen muestra que junit tiene una dependencia transitiva y apache.commons no la tiene

Estructura/sintaxis del POM

El pom mas sencillo que podemos tener es uno que solo define los datos del proyecto actual, por ejmplo:

<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>// esta info no debe tocarse <groupId>net.openwebinars</groupId> //nuestro dominio alreves <artifactId>simplest-project</artifactId> //nombre projecto <version>1</version> //version de nuestro proyecto </project>

el artifactID, groupId y versión es lo mas basico de una aplicación, es como el carnet de identidad del proyecto y es usado para hacer referencias en las dependencias.

todo proyecto tiene dependencias ocultas, ya que existe un super pom que tiene dependencias oficiales. Por ejemplo las definiciones del central repository, que es el repositorio oficial donde se publican las dependencias, seccion build con las definiciones habituales y asi muchas otras definiciones, estas al igual que la herencia en la POO se pueden ampliar y editar.

y para revisar todas las definiciones esto podemos utilizar:

 mvn help:effective-pom

Este comando devuelve un XML con las dependencias transitivas de la apliccacion, estilo pom completo con las dependencias transitivas. Inclus podemos crear un pom en base a esta herramienta:

 mvn help:effective-pom > effective-pom.xml

Dependencias

para declarar dependencias en nuestro POM debemos obligatoriamente definir el artifactId del proyecto,el groupId y la version pueden ser opcionales, siempre cuando se esten gestionando de forma jerarquica y tenemos un pom padre que define previamente esta informacion. En el Pom padre tendriamos la etiqueta dependencyManager y dar de alta a dependencias con sus versiones a utilizar, de esta forma los modulos hijos no utilizan otra versiones.

existen otros parametros que no siempre se definin en la dependencia, por ejemplo scope,typo,classifier:

Scope (ámbito por defecto es compile)

• Compile: en el caso de una aplicacion web, por ejemplo un war o jar, el empaquetado incluira las librerias utilizadas para el compilado
•  Provide: en el caso de generar un war, el empaquetado no incluira las librerias. De esta forma el proyecto utilizara las librerias que provee el servidor de aplicaciones, por ejemplo un GlassFish.
• o sea las dependencias sirven para compilar pero no para la distribucion de la aplicacion (empaquetado)
• Test: solo para ejecutar test, no se guardan las librerias en el empaquetado, no es transitiva a los projectos hijos.
• System
• runtime: las dependencias no se utilizan para compilar, solo ejecución

Classifier (es sources por defecto): 

suele no especificarse, pero en ocaciones podemos querer cambiar el sufijo que tendran los archivos generados al momento de compilar nuestro projecto.Por defecto se generan con la palabra "source"

 *.jar, *.pom, *.source.jar, *.test.sources.jar

Uso practico: Por ejemplo de tener una libreria open source editada, al momento de darla de alta en las dependencias podemos especificar el Classifier para que nos traiga la librería correcta.

podemos compilar nuestro proyecto utilizando la herramienta install-file, nos permite cambiar  el  Classifier,ID group,version, etc...  especifico:

mvn clean package install:install-file -Dfile=./target/nombre-projecto.jar -Dclassifier=someclassfiers -Dmaven.test.skip=true

dependency pluging

para ver el detalle de estos plugin podemos visitar la web de maven y revisar la sección goals, aca estarán los parámetros que podemos incluir, ojo que los parámetros se ingresan con  

-Dmdep.parametroDefinir=true (para ejecutarlo por fuera de la aplicacion) y no con -Dparametrodefinir=true

comandos mas utilizados:

 mvn dependency:tree  ver arbol de dependencias

mvn dependency:copy-dependencies copia dependencias de un proyecto, el resiltado lo guarda en la carpeta target/dependency

mvn dependency:analize  analiza dependencias de un proyecto, detecta dependencias que no estan siendo utilizadas.

Ciclo de vida o construcción

podemos ejecutar mvn clean con package,install o deploy:

mvn clean ...(package,install,deploy)

clean=borrarcontenido target

package= compilacion y posterior empaquetado de los fuentes en directorio target

install=instalacion en el repositorio local

deploy=despliegue en un repositorio de distribución remoto

plugins maven

un pluging es una libreria que se instala en el repositorio local de maven. Nos permiten ejecutar acciones en las faces de construccion de nuestro proyecto, recordar que el ciclo de construccion, incluye varias faces.

el plugin puede que requiera ciertas dependencias para realizar su accion, estas se deben definir dentro del pluging, pero no son consideradas dentro del ployecto general, solo son utilizadas en momento de ejecucion por el pluging

al momento de ejecutar nuestros comandos MAVEN lo realizamos ejecutando por detras plugings, por ejmplo:

 Plugins más conocidos

• maven-compiler-plugin
• maven-surefire-plugin
• maven-jetty-plugin
• maven-dependency-plugin
• maven-jar-plugin
• maven-war-plugin
• maven-deploy-plugin
• maven-resource-plugin
• hibernate-tools-maven-plugin
• cxf-codegen-maven-plugin
• spring-boot-maven-plugin

perfiles de configuración

Nos permite definir propiedades, pipeline de ejecución de plugings, librerías(dependencias) según el ambiente donde ejecutemos la aplicación, por ejemplo utilizar diferentes librerías según nuestro sistema operativo.

ejemplos:

Podemos determinar que solo se optimice el código al compilar cuando estamos en el ambiente de producción....en los otros ambiente la compilación será sin el plugging de optimización

otro ejemplo muy habitual: definir dependencias según la base de datos establecida.

 

Activación de los perfiles

habitualmente al momento de compilar la aplicación se determina, también en la sección <activateProfile> del pom o en un archivo setting del proyecto. Pero también se pueden activar según el sistema operativo del anfitrión o del JDK instalado

Creación e importación de proyectos de proyectos Maven

los archivos .clasphat, .setting no deben subirse al repoitorio

descargar el javadoc de las dependencias

JRE vs JDK