Gestión de proyectos con Maven

Gestión de proyectos con Maven

Herramienta de documentación de proyectos
¿Qué es Maven 2? Herramienta de compilación Herramienta de documentación de proyectos Herramienta para la gestión de dependencias en un proyecto.

Construcción de aplicaciones dirigida por patrones
Maven se puede definir como un proceso de aplicación de patrones a la infraestructura de construcción de proyectos orientada a alcanzar una gestión coherente de los proyectos software. Entendemos por construcción de proyectos los procesos de compilación, empaquetado, despliegue, testing, etc. Maven facilita: Builds Documentación Generación de informes Gestión de dependencias Gestión de la configuración del proyecto Gestión de versiones Distribución y despliegue del proyecto etc

Objetivos de Maven 2 Hacer el proceso de desarrollo más transparente: llegamos a un proyecto y tenemos que invertir tiempo en comprender el entorno de desarrollo. Acceso rápido al estado del proyecto. Facilitar la incorporación de nuevos desarrolladores al proyecto: Si se trabaja en todos los sitios de igual forma…. Dar acceso a todas las herramientas necesarias de forma uniforme. Evitar configuraciones inconsistentes. Aportar una infraestructura de desarrollo estandarizada e independiente del proyecto. Permitir al desarrollador centrarse en el proyecto en sí.

Ventajas y beneficios Estandarización
Configurar un entorno de desarrollo potente es fácil y rápido. Herramienta consolidada y estable. Gestión de dependencias con descarga automática. Generación automática del sitio web y javadoc del proyecto. Gestión del repositorio de APIs.

Repositorios remoto o local
Arquitectura Maven Estación de trabajo Repositorios remoto o local Plugin e.g. jar Plugin e.g. release Plugin e.g. surefire Proyectos gestionados Maven Core

Formato de los metadatos de proyectos común.
POM = Project Object Model = pom.xml Contiene los metadatos del proyecto. Localización de directorios, Desarrolladores, sistema de trazado de incidencias, dependencias, repositorios a utilizar, etc Ejemplo de POM: <project> <modelVersion>4.0.0</modelVersion> <groupId>es.uniovi.si</groupId> <artifactId>Piloto</artifactId> <name>Piloto para el Servicio de Informática</name> <version>0.1-SNAPSHOT</version> <packaging>jar</packaging> <dependencies/> <build/> […] POM mínimo

Organización de directorios estándar
Aprender una vez y aplicar siempre. Una vez familiarizados con la gestión de proyectos Maven, todos son iguales. src/main/java Application/Library sources src/main/resources Application/Library resources src/main/filters Resource filter files src/main/assembly Assembly descriptors src/main/config Configuration files src/main/webapp Web application sources src/test/java Test sources src/test/resources Test resources src/test/filters Test resource filter files src/site Site LICENSE.txt Project's license README.txt Project's readme

Forma común de construir las aplicaciones
El MOJO o GOAL sería equivalente a las tareas en ANT plugins usuario e.g. mvn install M2 generate- sources compile test install deploy package integration- test Fases estándar mojo bindings MOJO – Maven 2 Plugins Project

Repositorios de artefactos
Almacenan todo tipo de artefactos JARs, EARs, WARs, NBMs, EJBs, ZIPs, plugins, … Todas las interacciones del proyecto se realizan por medio del repositorio: Evita paths relativos Facilita el trabajo en equipo. Repositorio local Remoto e.g. <repositories> <repository> <id>maven2-snapshot</id> <releases> <enabled>true</enabled> </releases> <name>Maven Central Development Repository</name> <url> <layout>legacy|default</layout> </repository> </repositories>

Algunos repositorios públicos: ibiblio m1 JIRA upload requests m1 sync Conversion + sync ibiblio m2 JIRA upload requests m2 sync + conversion Codehaus m1 ObjectWeb m1 Apache m1 Jetty m1 Open Symphony m1 OS Java m1 partners

Estructura jerárquica Descarga automática de plugins Los plugins se toman directamente del repositorio. Estrategias configurables para el chequeo de actualizaciones. Chequeo diario por defecto Los repositorios remotos contienen metadatos Versiones, betas, próximas versiones, etc.

Gestión de dependencias
Maven aplica dependencias binarias « versión 1.0 o superior » A B <dependencies> <dependency> <groupId>com.acme</groupId> <artifactId>B</artifactId> <version>[1.0,)</version> <scope>compile</scope> </dependency> </dependencies> C Artifact Repository (Local) Artifact Repositories (Remote) Build C Busca A & B Busca A & B

Gestión de dependencias
Dependencias transitivas Posibilidad de excluir dependencias Los proyectos deberían ser modularizados Gestión de SNAPSHOTs Obtén siempre la última Actualización automática de dependencias Diaria por defecto. A Sólo necesita incluir A B C D

Taller práctico Instalación y configuración
Descarga de Maven 2. Descargamos la distribución binaria comprimida en zip de Establecer la variable M2_HOME apuntando al directorio de maven. Añadir el directorio bin de Maven al PATH ¡Ya tenemos MAVEN instalado!

Taller práctico Comprobamos la instalación
Vamos a comprobar que MAVEN está bien instalado. Para ello: Abrimos una ventana de comandos con setenv.bat Ejecutamos mvn -version

Comandos en Maven 2 Hay dos tipos de comandos en Maven 2 que pueden ejecutarse en proyectos (pom.xml) Mojos o Goals: Se agrupan en los plugins, e incluyen cosas como copia este conjunto de ficheros, compila este árbol de directorios, etc. mvn <groupId>:<artifactId>:<version>:<goal> Comandos del ciclo de vida Agrupaciones de mojos que juntos realizan un cometido común. Por ejemplo, el comando test ejecuta varios mojos secuencialmente que pertenecen a varios plugins diferentes. mvn <phaseId>

Taller práctico: Mi primer proyecto Maven 2
Una vez instalado, vamos a crear un proyecto java que se adecúe a la estructura que utiliza Maven 2 para aplicaciones java normales. Para ello: Creamos un directorio pruebamaven2 colgando de proyectos Creamos los directorios src/main/java Creamos dentro de src/main/java un javabean HolaMundoBean.java que guarde un mensaje de “Hola Mundo” en la propiedad saludo. Creamos el pom.xml en el raíz del proyecto: <project> <modelVersion>4.0.0</modelVersion> <groupId>es.uniovi.si</groupId> <artifactId>Piloto</artifactId> <name>Piloto para el Servicio de Informática</name> <version>0.1-SNAPSHOT</version> <packaging>jar</packaging> </project>

Taller práctico: Mi primer proyecto Maven 2
Una vez creado el POM, ejecutamos >mvn compile Y examinamos la estructura de directorios de nuevo. ¿Qué ha ocurrido?

Taller práctico Configuración del proxy
En la red de Uniovi estámos detrás de un proxy! Dado que Maven se conecta constantemente al repositorio, en caso de estar tras un proxy tenemos que configurarlo. Para ello, creamos el documento XML ${user.home}/.m2/settings.xml con: <settings> <proxies> <proxy> <active>true</active> <protocol>http</protocol> <host>proxy.uniovi.es</host> <port>8888</port> <nonProxyHosts>*.uniovi.es</nonProxyHosts> </proxy> </proxies> </settings>

Taller práctico Probamos a ejecutar mvn:test
Como podemos apreciar, el comando test implica la invocación de varios goals o plugins. Building Piloto para el Servicio de Informática task-segment: [test] [resources:resources] Using default encoding to copy filtered resources. [compiler:compile] Nothing to compile - all classes are up to date [resources:testResources] [compiler:testCompile] No sources to compile [surefire:test] No tests to run.

Taller práctico También podemos forzar la invocación de un mojo aisladamente: mvn compiler:compile (Ejecuta el mojo compile dentro del plugin compiler)

Plugins en Maven 2 Los plugins agrupan MOJOS o GOALS
Los MOJOS son equivalentes a las tareas de ANT y se vinculan a las distintas fases del ciclo de vida. En Tenemos la lista de plugins gestionados por el sitio de Maven 2. Examinar la página y el plugin clean. Core Plugins Clean Realiza un clean del entorno de desarrollo Compiler Implementa tareas relacionadas con la compilación Deploy Despliega el producto en un repositorio remoto Install Instala el producto en el repositorio local Resources Copia los recursos al directorio de output Site Genera un site sobre el proyecto Surefire Ejecuta los test de junit verifier Verifica ciertas condiciones de integración

Configuración de plugins
Tienen un comportamiento por defecto basándose en la estructura estándar de Maven 2, pero se pueden configurar. Para ello, sobrescribimos su declaración heredada del superPOM. Ejemplo: <build> <plugins> <plugin> <groupId><group id del plugin></groupId> <artifactId><nombre del plugin></artifactId> <configuration> ... Aquí sobrescribimos los elementos que deseamos reconfigurar con respecto al valor por defecto... </configuration> </plugin> </plugins> </build>

Taller práctico Vamos a forzar a que la compilación de nuestro proyecto se realice con Java 1.5 Editamos el pom.xml y añadimos lo siguiente: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> </build>

Taller práctico Gestión de dependencias
Vamos a añadir una dependencia a nuestro proyecto, concretamente, la versión de Junit. Para ello, añadimos al POM: <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> </dependency> </dependencies> Ejecutamos de nuevo mvn compile. ¿Qué ocurre? ¿Y si lo volvemos a hacer? Examinamos el repositorio local.

¿Cómo sé como declarar una dependencia? Necesito Log4J...
La información estará normalmente en las páginas de los desarrolladores. Otra alternativa, buscarlo en los repositorios y localizar sus coordenadas en él. Si no encontramos el jar en ningún repositorio Maven 2, lo podemos cargar directamente en nuestro repositorio local.

Taller práctico Examinar el repositorio por defecto de Maven repo1.maven.org y averiguar las coordenadas para la versión del log4J para Maven 2. Crear la dependencia en el pom.xml y disparar de nuevo la compilación del proyecto. Establecer ahora la dependencia con la versión 1.3-alpha8 del log4j. ¿Qué sucede?

Instalación de JARs externos en el repositorio local
Hemos visto como instalar nuestro jar generado por el proyecto en el repositorio. Es posible insertar JARs específicos en el repositorio local para utilizarlos en los builds. Deben ser colocados en el lugar adecuado para que sean correctamente encontrados por Maven. Para instalar un JAR específico en el repositorio local: mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> \ -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=jar Una vez en el rep. local, podemos crear la dependencia en el pom.xml <dependency> <groupId><group-id></groupId> <artifactId><artifact-id></artifactId> <version><version></version> </dependency>

Taller práctico Descargar la versión 1.3alpha8 de Log4J accediendo a su página web. Instalarla en el repositorio local mediante mvn install:install y comprobar que se ha añadido correctamente en su correspondiente directorio. Añadir la dependencia al proyecto y ejecutar mvn compile para comprobar que lo encuentra adecuadamente en el repositorio local.

Creación de proyectos Maven por arquetipos
Podemos crear un esquema de proyecto por defecto invocando: mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app El comando archetype:create fuerza la creación de un proyecto con la distribución estándar de directorios. Todas las dependencias se descargarán automáticamente, y la estructura de directorios se creará de acuerdo a éstas. Se puede forzar a utilizar plantillas más específicas. Ejemplo: -DarchetypeArtifactId=maven-archetype-webapp for instance

Creación de proyectos Maven por arquetipos
Tipo de aplicación maven-archetype-archetype Arquetipo para la creación de arquetipos maven-archetype-j2ee-simple Crea un proyecto JEE completo (EAR) con directorios y subproyectos para EJBs, Componentes Web, etc. maven-archetype-mojo Para la creación de plugins Maven 2 maven-archetype-quickstart Proyecto Java simple, para la generación de JARs. Es el arquetipo por defecto. maven-archetype-site Complementa el proyecto con una estructura para su sitio web con diferentes formatos. maven-archetype-webapp Crea una aplicación web simple con una JSP Hola Mundo

Taller práctico Creación de mi primer proyecto
Vamos a crear un proyecto MAVEN basándonos en el arquetipo por defecto. Un arquetipo MAVEN es una plantilla base, que combinada con información específica del proyecto supone un proyecto MAVEN completo. Desde la carpeta entorno, mvn archetype:create -DgroupId=com.uniovi.si -DartifactId=piloto ¿Qué ha sucedido?

Maven a creado el proyecto basándose en el arquetipo por defecto y ha descargado sus dependencias. Examinar el directorio creado Examinar el pom.xml

El repositorio local ¿Qué sucede con las dependencias de Maven 2?
C:\Documents and Settings\Username\.m2 Ventajas: No se necesita guardar nada en el repositorio salvo nuestro propio código fuente, ahorrando espacio y tiempo de rebuilt y descarga. Se pueden descargar las dependencias de un repositorio local a nuestra intranet, evitando hacerlo siempre del ibiblio.

Fases principales en un proyecto Maven
validate – Valida que el proyecto es correcto y que toda la información necesaria está presente. compile – Compila el código fuente del proyecto. test – Ejecuta los test unitarios sobre el proyecto. Estos no deben requerir que el proyecto sea empaquetado o desplegado. package –Toma el código fuente compilado y lo empaqueta en el formato que se haya especificado en el POM, como por ejemplo, un fichero jar install – instala el paquete en el repositorio local para que pueda ser utilizado como dependencia por otros proyectos locales. deploy – Copia el paquete final a un repositorio remoto para compartirlo con otros desarrolladores o proyectos.

Compilación de proyectos
Maven hereda del superpom la descripción de las tareas básicas de compilación, test, empaquetado, etc. Ejemplo: > mvn compile [INFO] [INFO] Building Maven Quick Start Archetype [INFO] task-segment: [compile] [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: \ checking for updates from central ... [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: \ [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 1 source file to <dir>/my-app/target/classes [INFO] [INFO] BUILD SUCCESSFUL [INFO] Total time: 3 minutes 54 seconds [INFO] Finished at: Fri Sep 23 15:48:34 GMT-05: [INFO] Final Memory: 2M/6M

Entramos en el directorio piloto Compilamos la aplicación creada por defecto: mvn compile Probamos la aplicación corriendo las pruebas unitarias. mvn test También podemos compilar los test sin necesidad de ejecutarlos. mvn test-compile

Podemos empaquetar la aplicación: mvn package E instalarla: mvn install Ahora el jar que contiene la aplicación se encuentra instalado en el repositorio local de Maven, de forma que puede ser utilizada como dependencia en otros proyectos. TODO: Examinar el directorio .m2 y buscar el jar instalado.

Repositorios para la descarga automática
El uso de los repositorios es transparente para el usuario de Maven Por defecto, Maven busca el repositorio general ibiblio Podemos forzar el uso de otros repositorios, sobrescribiendo el pom.xml. Por ejemplo, para buscar el plugin de eclipse: <project> ... <repositories> <repository> <id>m2 plugin</id> <url>m2eclipse.codehaus.org</url> </repository> </repositories> </project> Ibiblio.org - Public library and digital archive

Taller práctico Generación de descriptores proy.
Maven genera descriptores de proyecto para diversos IDEs (idea, IntelliJ, Eclipse, etc.) Para crear el descriptor del proyecto Eclipse: Ejecutamos mvn eclipse:eclipse Examinamos el fichero .project Arrancamos Eclipse e importamos el proyecto recién creado. ¿Está bien importado? El descriptor generado hace referencia a una variable de entorno M2_REPO que debería apuntar a ${user.home}/.m2/repository Entrar en Window/Preferences/Java/Build Path/ClassPath Variables y darla de alta

Gestión de recursos en el classpath
En cualquier aplicación podemos tener otros recursos que no son exclusivamente código fuente y que deben ser distribuidos dentro del fichero JAR. Ej: ficheros properties, xml, Resource Bundles, etc. Para ello Maven reserva por defecto un directorio (src/main/resources) de tal forma que todo lo que metamos en él irá al raíz del fichero JAR.

Taller práctico Adición de otros recursos al Jar
Volvemos a la estructura del proyecto. Creamos el directorio Piloto/src/main/resources/META-INF Creamos dentro de éste el fichero application.properties. Empaquetamos de nuevo la aplicación Abrimos el JAR una vez creado para comprobar donde se encuentra el ficheros application.properties.

Gestión de recursos de testing en el classpath
Al igual que las clases principales de la aplicación, es posible que las clases que implementan las pruebas unitarias necesiten de otros recursos propios. Para ello Maven reserva por defecto un directorio (src/test/resources) de tal forma que todo lo que metamos en él irá al raíz del fichero JAR.

Filtrado dinámico de ficheros de recursos en el classpath
Es posible que algunos de las propiedades contenidas en los ficheros de recursos deban ser establecidas en tiempo de compilación. Maven facilita la utilidad de filtrado, que nos permite dejar ciertos valores abiertos referenciando variables que serán resueltas por MAVEN buscando: En el pom.xml En el settings.xml En un fichero properties externo En una propiedad del sistema

Filtrado dinámico de ficheros de recursos en el classpath
De esta forma, podemos dejar abierto el valor de una propiedad del application.properties: propiedad= ${<property name>} Y establecer el valor de property name en cualquiera de los lugares antes enumerados. Esto permite hacer estructuras de proyectos más genéricas y reutilizables

Taller práctico Filtrado dinámico de recursos
En primer lugar, debemos complementar el pom.xml, añadiendo: <project> … <dependencies> </dependencies> <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build> </project> Al activar el filtrado tenemos que sobrescribir la definición por defecto del recurso, por lo que debemos establecer el directorio de nuevo como directorio de recursos (ya lo está en el superpom!).

Vamos a complementar el application.properties estableciendo las propiedades application.name y application.version y haciendo que ambas sean tomadas del pom.xml # application.properties application.name=${project.name} application.version=${project.version} Ya podemos forzar el filtrado de los ficheros de recursos mvn process-resources

Comprobamos que el fichero properties ha sido parseado en target/classes/META- INF/application.properties. # application.properties application.name=piloto application.version=1.0-SNAPSHOT

Ahora vamos a hacer que recupere una cadena de texto de un fichero de recursos externo. Creamos src/main/filters/filter.properties: # filter.properties my.filter.value=Hola Mundo! Y lo enlazamos al proceso en el pom.xml <build> <filters> <filter>src/main/filters/filter.properties</filter> </filters> …

Otra alternativa es colocar la propiedad como tal en el pom.xml … </build> <properties> <my.filter.value>Hola Mundo!</my.filter.value> </properties> O bien, pasárselo como parámetro a Maven en la misma invocación mvn process-resources "-Dcommand.line.prop=hello again"

Excepciones en el filtrado
Hay recursos que no deben ser filtrados: Ej. Archivos binarios como imágenes. Para evitarlo, podemos establecer excepciones a los patrones de filtrado. <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <excludes> <exclude>images/**</exclude> </excludes> </resource> <includes> <include>images/**</include> </includes> </resources> </build>

Multiproyectos El escenario real suele ser más complicado que la gestión de proyectos simples. Diferentes proyectos dependen de diferentes versiones de los mismos proyectos que se pueden estar generando en paralelo. Ejemplo: Una aplicación EAR puede contener Un proyecto web Varios EJBs (proyectos ejb) Uno o varios jars con librerías de clases.

Multiproyectos Maven2 contempla el concepto de multiproyecto, permitiendo coordinar varios proyectos completos en un proyecto maestro que orqueste los procesos del ciclo de vida. Permite especificar las dependencias entre proyectos para realizar los procesos de compilación en el orden adecuado. Unifica la construcción de todos los subproyectos desde un único POM

Taller práctico: Mi primer multiproyecto
Vamos a crear un multiproyecto que contenga dos proyectos simples de Maven Para ello: Creamos una carpeta multiproyecto colgando de proyectos. Utilizando el script para la creación de arquetipos, creamos los proyectos parteA y parteB dentro del groupId es.uniovi.si En parteA eliminamos la clase App.java y metemos en el mismo paquete el HolaMundoBean que hemos creado antes. En parteB modificamos App.java para que instancie y use el HolaMundoBean. Intentamos compilar parteA y parteB. ¿Qué ocurre?

La parteB requiere del uso de una clase definida en la parteA. Alternativas: Instalamos antes parteA en el repositorio y especificamos la dependencia en parteB para que acceda al mismo y se lo baje. Creamos un multiproyecto que contenga ambos proyectos y coordine su construcción para evitar los problemas de dependencias. Obviamente, vamos a hacer lo segundo

Creamos el archivo pom.xml en la carpeta multiproyecto: <project xmlns=“ xmlns:xsi=“ xsi:schemaLocation=" <modelVersion>4.0.0</modelVersion> <groupId>es.uniovi.si</groupId> <artifactId>multiproyecto</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <modules> <module>parteA</module> <module>parteB</module> </modules> ...

<dependencyManagement> <dependencies> <dependency> <groupId>es.uniovi.si</groupId> <artifactId>parteA</artifactId> <version>${project.version}</version> </dependency> </dependencies> </dependencyManagement> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </project>

Editamos el pom.xml de la parteA <project xmlns=" xmlns:xsi=" xsi:schemaLocation=" <parent> <groupId>es.uniovi.si</groupId> <artifactId>multiproyecto</artifactId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>parteA</artifactId> <packaging>jar</packaging> </project>

Editamos el pom.xml de la parteB <project xmlns=" xmlns:xsi=" xsi:schemaLocation=" <parent> <groupId>es.uniovi.si</groupId> <artifactId>multiproyecto</artifactId> <version>1.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>parteB</artifactId> <packaging>jar</packaging> <dependencies> <dependency> <artifactId>parteA</artifactId> </dependency> </dependencies> </project>

Vamos al directorio raíz del multiproyecto y ejecutamos: mvn compile ¿Qué ha ocurrido? Resuelto en Multiproyecto.zip

Instalación del plugin de eclipse
Hasta ahora estamos haciendo las cosas “a mano”. Existe un plugin de Eclipse para integrarlo con Maven2. Para instalarlo: Arrancamos Eclipse Establecemos el proxy en window/preferences Vamos a Help/Software Updates/Find & Install. Damos de alta como nuevo site remoto la url: Al aceptar cargará los paquetes disponibles, y seleccionamos Maven Integration

Taller práctico: Creación de un proyecto Web
Creamos la estructura de directorios con el arquetipo maven-archetype-webapp Construimos el descriptor de proyecto de eclipse y lo importamos desde el mismo. En Eclipse, botón derecho sobre el proyecto - Properties. Vamos a donde dice Tomcat y, en la solapa General, clickeamos en Is a Tomcat Project. Subdirectory to set as web application root (optional), seteamos la ruta que el Maven usa en su archetype como root de la webapp: /src/main/webapp (la ruta es relativa al root del proyecto).

Taller práctico: Creación de un proyecto Web
Arrancamos el Tomcat Vamos a Cambiamos algo en la index.jsp y volvemos a la página de tomcat.

Taller práctico Construir un multiproyecto compuesto de:
Artefacto MiLibreria: Fichero jar donde se incluya una clase es.uniovi.si.Mates con los métodos suma y resta que reciba y devuelva Integers Artefacto MiWeb: Fichero war que contenga una aplicación web que invoque la clase Mates desde su index.jsp

Taller práctico Pasos: Crear la carpeta MiSite
Dentro, crear los dos proyectos usando los arquetipos que conocemos. Crear el pom de MiSite Establecer las dependencias necesarias en los subproyectos. Crear el descriptor de eclipse a nivel de MiSite ¿Qué ocurre? Crear la clase Mates en el proyecto de MiLibreria

Taller práctico Crear index.jsp tal que:
page import="es.uniovi.si.Mates" %> <html> <body> <% Mates m = new Mates(); %> 2+2 son: <%=m.suma(2,2) %> </body> </html>

Taller práctico Una vez tengamos todo lo necesario, ejecutar mvn package a nivel de MiSite, y comprobar que todo está donde debe estar Desplegar el war generado en Tomcat y comprobarlo arrancándolo fuera de eclipse (dentro no va a funcionar!) Resuelto en MiSite.zip

Desarrollo de Mojos y Plugins
Maven 2 incorpora gran diversidad de plugins para hacer casi cualquier cosa relacionada con el ciclo de vida del proyecto. Problema: Exige que nos adecuemos a su estructura de directorios de trabajo, y eso no siempre es posible: Código heredado Convivencia con otros entornos de desarrollo que imponen sus propios modelos Etc.

Desarrollo de Mojos y Plugins
Para salvar estas situaciones, podemos desarrollar nuestros propios plugins, y: Bien invocar sus mojos directamente de manera aislada Bien insertarlos en el ciclo de vida del proyecto, en aquella fase donde más nos interese tenerlo. Para poder usarlo será necesario: Implementar el mojo como plugin de maven Instalarlo en el repositorio local, o en uno de los remotos apuntados por nuestro POM. Referenciarlo en el POM del proyecto que lo necesita usar para establecer la dependencia. Configurarlo.

Taller práctico: Mi primer MOJO
Creamos desde eclipse un nuevo proyecto Maven 2 tal que: Sea de tipo simple –no usamos arquetipo. Se ubique en la carpeta proyectos/mimojo El artefacto sea log El grupo es.uniovi.si Empaquetamiento jar Tenemos el esqueleto de un proyecto Maven 2 por defecto, y lo tendremos que adaptar para que se trate de un proyecto para plugins

Antes de nada, vamos a crear nuestra clase que implemente el mojo. Para ello: Añadimos el jar de la distribución de Maven al Java Build Path del proyecto. Creamos es.uniovi.si.UnioviLog tal que. Extienda la clase AbstractMojo. Muestre un mensaje por pantalla en su método execute. Contenga el siguiente comentario de sintaxis javadoc a nivel de clase: /** * Muestra mensajes de log print */ public class...

Ya tenemos implementada la clase. El valor del comentario goal es la referencia que utilizará Maven para referenciar el mojo dentro del plugin. Ahora editamos el pom.xml para que sepa que tiene que empaquetar un plugin. Packaging: maven-plugin Dependencia: org.apache.maven:maven-plugin- api:2.0 Listo! Instalamos el plugin y comprobamos que esté bien subido al repositorio.

Taller práctico: Usando mi MOJO
Ahora tenemos que entrar en el proyecto que tenemos empezado y establecer la dependencia del nuevo plugin para poder ejecutarlo. <plugin> <groupId>es.uniovi.si</groupId> <artifactId>log</artifactId> </plugin> Ya podemos ejecutarlo directamente sin necesidad de meterlo en el ciclo de vida, con la sintaxis: mvn <groupId>:<artifactId>:<version>:<goal>

Modificación del ciclo de vida estándar
Tenemos un mojo dentro de un plugin que está dado de alta en nuestro proyecto. Podemos invocarlo explícitamente, pero ... ¿cómo podemos insertarlo en el ciclo de vida del proyecto? Para incluirlo en una de las fases del ciclo de vida de Maven, utilizamos el elemento execution que se anida al elemento plugin en el pom.xml

Modificación del ciclo de vida estándar
Modificar el pom.xml del proyecto que tiene la dependencia del plugin y añadir lo siguiente: <artifactId>log</artifactId> <executions> <execution> <phase>process-sources</phase> <goals> <goal>print</goal> </goals> </execution> </executions>

Paso de información a los plugins
Los plugins necesitan información para poder realizar su cometido, de dos tipos: Parámetros de configuración que le pasemos cuando declaremos el plugin. Información relativa al ciclo de vida del proyecto (por ejemplo, directorios fuente.) El paso de información a los plugins se realiza mediante una técnica basada en inyección de dependencias un tanto especial.

Configuración del plugin
Si queremos poder configurar parámetros del plugin, es necesario: Crear un atributo privado para alojar el valor de configuración que deseamos establecer. Decirle a Maven que ese atributo es configurable mediante una etiqueta de sintaxis javadoc como la de goal. /** * The greeting to display. * expression="HolaMundo" */ private String saludo;

Configuración del plugin
Una vez tengamos el plugin preparado para recibir el parámetro, se lo hacemos llegar por medio del pom.xml. <configuration> <saludo>Welcome</saludo> </configuration> ¿Porqué no hacemos una inicialización Java? ¿Dónde está el método setter?

Taller práctico Configurando el plugin
Extender el plugin log para que reciba un parámetro mensaje y sea éste el que imprima por pantalla. El parámetro estará inicializacon con la cadena “Hola Mundo!” (Resuelto en la versión 2 del piloto)

Acceder a información del ciclo de vida del proyecto
Maven permite utilizar expresiones para inicializar los parámetros configurables de un plugin. Por ejemplo: ${project.build.directory} Permite conocer el directorio donde se va a construir el proyecto. Éste es el motivo por el que no se realiza la inicialización de los parámetros valiéndose del lenguaje (no podría estipularse esto)

Expresiones en los parámetros.
Existen multitud de variables para referenciar diferentes atributos del proyecto. Algunos: project.distributionManagementArtifactRepository project.artifact project.parent project.file project.artifacts project.parentArtifact project.pluginArtifacts project.remoteArtifactRepositories project.pluginArtifactRepositories project.attachedArtifact

(Resuelto en la versión 3.0)
Taller práctico Completar el plugin para: Añadir un parámetro artefacto de tipo Object al plugin Inicializarlo con la expresión que nos devuelve el nombre del artefacto. Extender el método execute para que en el mensaje muestre también el valor de artefacto, invocando su método toString(). (Resuelto en la versión 3.0)

Integrando ANT con Maven2
Maven 2 también permite desarrollar plugins en ANT, lo cual facilita la reutilización de proyectos y la integración con código heredado. Para desarrollar un MOJO ANT en un plugin Maven 2, tendremos que facilitar: La declaración de la tarea en ANT que deseamos integrar para que Maven 2 la invoque. El descriptor del MOJO ANT.

Taller práctico: Completando el plugin log
Vamos a añadir un MOJO ANT al plugin que ya tenemos empezado. Los scripts necesarios deben estar colocados en src/main/scripts (creamos la carpeta) En primer lugar, vamos a declarar la tarea saluda en un fichero hola.build.xml. <project> <target name="saluda"> <echo>Hola Mundo!!!!</echo> </target> </project>

Una vez declarada la tarea saluda, declaramos su descriptor. Será otro fichero llamado hola.mojos.xml. <pluginMetadata> <mojos> <mojo> <goal>hola</goal> <call>saluda</call> <description> Saluda al mundo!!!! </description> </mojo> </mojos> </pluginMetadata>

Tenemos que añadir ciertas dependencias al pom.xml del plugin: <dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-script-ant</artifactId> <version>2.0.2</version> </dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.6.5</version>

Y Finalmente, reconfigurar el plugin maven- plugin-plugin para actualizar sus dependencias. <build> <plugins> <plugin> <artifactId>maven-plugin-plugin</artifactId> <version>2.3</version> <dependencies> <dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-plugin-tools-ant</artifactId> <version>2.0.1</version> </dependency> </dependencies> </plugin> </plugins> </build>

Ya podemos instalar de nuevo el plugin mvn install E Intentar ejecutar el mojo que acabamos de crear. mvn es.uniovi.si:log:hola Resultado: ... [INFO] [log:hola] saluda: [echo] Hola Mundo!!!!

Adaptando Maven a nuestro entorno
Puede que en ciertas ocasiones necesitemos adaptar el proceso Maven a código heredado. Por ejemplo: El código fuente está alojado en la carpeta /src. Estos parámetros están declarados en el superPOM: <directory>target</directory> <outputDirectory>target/classes</outputDirectory> <finalName>${project.artifactId}${project.version}</finalName> <testOutputDirectory>target/test-classes</testOutputDirectory> <sourceDirectory>src/main/java</sourceDirectory> <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory> <testSourceDirectory>src/test/java</testSourceDirectory>

Taller práctico: Adaptar Maven a nuestro entorno
Supongamos que nuestro proyecto tiene los fuentes en la carpeta /src. Para cambiar este parámetro: Sobrescribimos la propiedad sourceDirectory en la sección build del pom.xml para que apunte a /src. Crear una nueva clase o mover la que tenemos para ver si compila Compilar el proyecto.

Taller práctico Seguimos teniendo un problema: En el código heredado tenemos mezclados los ficheros que implementan pruebas unitarias y los que implementan las clases normales. En lugar de redireccionar la carpeta de fuentes de maven –donde seguiría todo mezclado- queremos separar los fuentes antes de la compilación, de forma que: Las clases Test*.* se copien a la carpeta de Maven para pruebas Las demás, a la carpeta de fuentes

¿A qué fase lo vincularemos?
Taller práctico Creamos la carpeta /src con: HolaMundo.java TestHolaMundo.java Desarrollamos un plugin de ant para realizar la separación de archivos y que cada tipo de clase se copie a su correspondiente ubicación para que Maven compile lo que necesite. ¿A qué fase lo vincularemos?

Gestión de proyectos con Maven

Presentaciones similares

Presentación del tema: "Gestión de proyectos con Maven"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Gestión de proyectos con Maven

Presentaciones similares

Presentación del tema: "Gestión de proyectos con Maven"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback