Gestin de proyectos con Maven

Herramienta de compilacin Herramienta de Herramienta para la gestin de documentacin de proyectos dependencias en un proyecto.

Maven se puede definir como un proceso de aplicacin de patrones a la infraestructura de construccin de proyectos orientada a alcanzar una gestin coherente de los proyectos software. Entendemos por construccin de proyectos los procesos de compilacin, empaquetado, despliegue, testing, etc. Maven facilita:
Builds Documentacin Generacin de informes Gestin de dependencias Gestin de la configuracin del proyecto Gestin de versiones Distribucin y despliegue del proyecto etc

 Hacer el proceso de desarrollo ms transparente: Acceso rpido al estado del proyecto. Facilitar la incorporacin 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.

llegamos a un proyecto y tenemos que invertir tiempo en comprender el entorno de desarrollo.

 Estandarizacin Configurar un entorno de desarrollo potente es fcil y rpido. Herramienta consolidada y estable. Gestin de dependencias con descarga automtica. Generacin automtica del sitio web y javadoc del proyecto. Gestin del repositorio de APIs.

Plugin e.g. jar Proyectos gestionados Plugin e.g. surefire Plugin e.g. release Estacin de trabajo Repositorios remoto o local

Maven Core

 POM = Project Object Model = pom.xml Contiene los metadatos del proyecto. Localizacin 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 Informtica</name> <version>0.1-SNAPSHOT</version> <packaging>jar</packaging> <dependencies/> POM mnimo <build/> []

 Aprender una vez y aplicar siempre. Una vez familiarizados con la gestin de proyectos Maven, todos son iguales.
src/main/java src/main/resources src/main/filters Application/Library sources Application/Library resources Resource filter files

src/main/assembly
src/main/config src/main/webapp src/test/java src/test/resources src/test/filters src/site LICENSE.txt README.txt

Assembly descriptors
Configuration files Web application sources Test sources Test resources Test resource filter files Site Project's license Project's readme

El MOJO o GOAL sera equivalente a las tareas en ANT M2

generatesources compile test mojo package integrationtest

mojo mojo

plugins

usuario
e.g. mvn install

mojo

install
mojo deploy bindings

Fases estndar

MOJO Maven 2 Plugins Project

http://mojo.codehaus.org/

 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

Repositorio Remoto

e.g. http://ibiblio.org/maven2

<repositories> <repository> <id>maven2-snapshot</id> <releases> <enabled>true</enabled> </releases> <name>Maven Central Development Repository</name> <url>http://snapshots.maven.codehaus.org/maven2</url> <layout>legacy|default</layout> </repository> </repositories>

 Algunos repositorios pblicos:

JIRA upload requests m1
sync + conversion Conversion + sync

ibiblio m1

ibiblio m2

JIRA upload requests m2

Codehaus m1

ObjectWeb m1

Apache m1

Jetty m1
partners

Open Symphony m1

OS Java m1

 Estructura jerrquica Descarga automtica de plugins Los plugins se toman directamente del repositorio. Estrategias configurables para el chequeo de actualizaciones.
Los repositorios remotos contienen metadatos
Chequeo diario por defecto

Versiones, betas, prximas versiones, etc.

 Maven aplica dependencias binarias

versin 1.0 o superior
<dependencies> <dependency> <groupId>com.acme</groupId> <artifactId>B</artifactId> <version>[1.0,)</version> <scope>compile</scope> </dependency> </dependencies>

Busca A & B

Build C
Busca A & B

Artifact Repository (Local)

Artifact Repositories (Remote)

 Dependencias transitivas
Posibilidad de excluir dependencias Los proyectos deberan ser modularizados
A
Slo necesita incluir A

Gestin de SNAPSHOTs
Obtn siempre la ltima

Actualizacin automtica de dependencias

Diaria por defecto.

 Descarga de Maven 2. Descargamos la distribucin binaria comprimida en zip de

http://maven.apache.org/

Establecer la variable M2_HOME apuntando al directorio de maven. Aadir el directorio bin de Maven al PATH Ya tenemos MAVEN instalado!

Vamos a comprobar que MAVEN est bien instalado. Para ello:

Abrimos una ventana de comandos con setenv.bat Ejecutamos mvn -version

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
mvn <groupId>:<artifactId>:<version>:<goal>

copia este conjunto de ficheros, compila este rbol de directorios, etc.

Comandos del ciclo de vida

Agrupaciones de mojos que juntos realizan un cometido comn. Por ejemplo, el comando test ejecuta varios mojos secuencialmente que pertenecen a varios plugins diferentes.
mvn <phaseId>

Una vez instalado, vamos a crear un proyecto java que se adece 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 raz del proyecto:

<project> <modelVersion>4.0.0</modelVersion> <groupId>es.uniovi.si</groupId> <artifactId>Piloto</artifactId> <name>Piloto para el Servicio de Informtica</name> <version>0.1-SNAPSHOT</version> <packaging>jar</packaging> </project>

Una vez creado el POM, ejecutamos Y examinamos la estructura de directorios de nuevo. Qu ha ocurrido?

>mvn compile

 En la red de Uniovi estmos detrs 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>

http://maven.apache.org/guides/mini/guide-proxies.html

Probamos a ejecutar mvn:test Como podemos apreciar, el comando test implica la invocacin de varios goals o plugins. Building Piloto para el Servicio de Informtica
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] Using default encoding to copy filtered resources. [compiler:testCompile] No sources to compile [surefire:test] No tests to run.

Tambin podemos forzar la invocacin de un mojo aisladamente:

mvn compiler:compile

(Ejecuta el mojo compile dentro del plugin compiler)

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 http://maven.apache.org/plugins/index.html Tenemos la lista de plugins gestionados por el sitio de Maven 2. Examinar la pgina y el plugin clean.
Realiza un clean del entorno de desarrollo Implementa tareas relacionadas con la compilacin Despliega el producto en un repositorio remoto Instala el producto en el repositorio local Copia los recursos al directorio de output Genera un site sobre el proyecto Ejecuta los test de junit Verifica ciertas condiciones de integracin

Core Plugins Clean Compiler Deploy Install Resources Site Surefire verifier

Tienen un comportamiento por defecto basndose en la estructura estndar de Maven 2, pero se pueden configurar. Para ello, sobrescribimos su declaracin 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>

Vamos a forzar a que la compilacin de nuestro proyecto se realice con Java 1.5 Editamos el pom.xml y aadimos 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>

Vamos a aadir una dependencia a nuestro proyecto, concretamente, la versin 3.8.1 de Junit. Para ello, aadimos 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.

La informacin estar normalmente en las pginas de los desarrolladores. Otra alternativa, buscarlo en los repositorios y localizar sus coordenadas en l. Si no encontramos el jar en ningn repositorio Maven 2, lo podemos cargar directamente en nuestro repositorio local.

Examinar el repositorio por defecto de Maven repo1.maven.org y averiguar las coordenadas para la versin 1.2.11 del log4J para Maven 2. Crear la dependencia en el pom.xml y disparar de nuevo la compilacin del proyecto. Establecer ahora la dependencia con la versin 1.3-alpha8 del log4j. Qu sucede?

 Hemos visto como instalar nuestro jar generado por el proyecto en el repositorio. Es posible insertar JARs especficos 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 especfico 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>

Descargar la versin 1.3alpha8 de Log4J accediendo a su pgina web. Instalarla en el repositorio local mediante mvn install:install y comprobar que se ha aadido correctamente en su correspondiente directorio. Aadir la dependencia al proyecto y ejecutar mvn compile para comprobar que lo encuentra adecuadamente en el repositorio local.

Podemos crear un esquema de proyecto por defecto invocando:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

Todas las dependencias se descargarn automticamente, y la estructura de directorios se crear de acuerdo a stas. Se puede forzar a utilizar plantillas ms especficas. Ejemplo:
-DarchetypeArtifactId=maven-archetype-webapp for instance

El comando archetype:create fuerza la creacin de un proyecto con la distribucin estndar de directorios.

Arquetipo maven-archetypearchetype maven-archetype-j2eesimple maven-archetype-mojo maven-archetypequickstart maven-archetype-site maven-archetype-webapp

Tipo de aplicacin Arquetipo para la creacin de arquetipos Crea un proyecto JEE completo (EAR) con directorios y subproyectos para EJBs, Componentes Web, etc. Para la creacin de plugins Maven 2 Proyecto Java simple, para la generacin de JARs. Es el arquetipo por defecto. Complementa el proyecto con una estructura para su sitio web con diferentes formatos. Crea una aplicacin web simple con una JSP Hola Mundo

Vamos a crear un proyecto MAVEN basndonos en el arquetipo por defecto. Un arquetipo MAVEN es una plantilla base, que combinada con informacin especfica del proyecto supone un proyecto MAVEN completo. Desde la carpeta entorno, Qu ha sucedido?

mvn archetype:create -DgroupId=com.uniovi.si -DartifactId=piloto

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

 validate Valida que el proyecto es correcto y que toda la informacin necesaria est presente. compile Compila el cdigo 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 cdigo 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.

Maven hereda del superpom la descripcin de las tareas bsicas de compilacin, test, empaquetado, etc. Ejemplo:

> mvn compile

[INFO] ----------------------------------------------[INFO] Building Maven Quick Start Archetype [INFO] task-segment: [compile] [INFO] ----------------------------------------------[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: \ checking for updates from central ... [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: \ checking for updates from central ... [INFO] [resources:resources] ... [INFO] [compiler:compile] Compiling 1 source file to <dir>/my-app/target/classes [INFO] -----------------------------------------------[INFO] BUILD SUCCESSFUL [INFO] -----------------------------------------------[INFO] Total time: 3 minutes 54 seconds [INFO] Finished at: Fri Sep 23 15:48:34 GMT-05:00 2005 [INFO] Final Memory: 2M/6M

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

Podemos empaquetar la aplicacin: mvn package E instalarla: mvn install Ahora el jar que contiene la aplicacin 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.

 El uso de los repositorios es transparente para el usuario de Maven Por defecto, Maven busca el repositorio general ibiblio
Ibiblio.org - Public library and digital archive

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>

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

Est bien importado? El descriptor generado hace referencia a una variable de entorno M2_REPO que debera apuntar a ${user.home}/.m2/repository Entrar en Window/Preferences/Java/Build Path/ClassPath Variables y darla de alta

En cualquier aplicacin podemos tener otros recursos que no son exclusivamente cdigo 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 raz del fichero 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 aplicacin Abrimos el JAR una vez creado para comprobar donde se encuentra el ficheros application.properties.

Al igual que las clases principales de la aplicacin, 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 raz del fichero JAR.

Es posible que algunos de las propiedades contenidas en los ficheros de recursos deban ser establecidas en tiempo de compilacin. Maven facilita la utilidad de filtrado, que nos permite dejar ciertos valores abiertos referenciando variables que sern resueltas por MAVEN buscando:
1. 2. 3. 4. En En En En el pom.xml el settings.xml un fichero properties externo una propiedad del sistema

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 ms genricas y reutilizables

Al activar el filtrado tenemos <project> que sobrescribir la definicin por defecto del recurso, por lo <dependencies> que debemos establecer el directorio de nuevo como </dependencies> directorio de recursos (ya lo <build> est en el superpom!). <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build> </project>

En primer lugar, debemos complementar el pom.xml, aadiendo:

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/METAINF/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, pasrselo como parmetro a Maven en la misma invocacin

mvn process-resources "-Dcommand.line.prop=hello again"

Hay recursos que no deben ser filtrados: Ej. Archivos binarios como imgenes. 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> <resource> <directory>src/main/resources</directory> <includes> <include>images/**</include> </includes> </resource> </resources> </build>

El escenario real suele ser ms complicado que la gestin de proyectos simples. Diferentes proyectos dependen de diferentes versiones de los mismos proyectos que se pueden estar generando en paralelo. Ejemplo:
Una aplicacin EAR puede contener
Un proyecto web Varios EJBs (proyectos ejb) Uno o varios jars con libreras de clases.

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 compilacin en el orden adecuado. Unifica la construccin de todos los subproyectos desde un nico POM

Vamos a crear un multiproyecto que contenga dos proyectos simples de Maven Para ello:

Intentamos compilar parteA y parteB. Qu ocurre?

Creamos una carpeta multiproyecto colgando de proyectos. Utilizando el script para la creacin 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.

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 construccin para evitar los problemas de dependencias.

Obviamente, vamos a hacer lo segundo

Creamos el archivo pom.xml en la carpeta multiproyecto:

<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"> <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> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

Editamos el pom.xml de la parteA

<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"> <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="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"> <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> <groupId>es.uniovi.si</groupId> <artifactId>parteA</artifactId> </dependency> </dependencies> </project>

Vamos al directorio raz del multiproyecto y ejecutamos: Qu ha ocurrido?

mvn compile

Resuelto en Multiproyecto.zip

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:
http://m2eclipse.codehaus.org

Al aceptar cargar los paquetes disponibles, y seleccionamos Maven Integration

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, botn 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).

Arrancamos el Tomcat Vamos a http://localhost:8080 Cambiamos algo en la index.jsp y volvemos a la pgina de tomcat.

Construir un multiproyecto compuesto de:

Artefacto MiLibreria:
Fichero jar donde se incluya una clase es.uniovi.si.Mates con los mtodos suma y resta que reciba y devuelva Integers

Artefacto MiWeb:
Fichero war que contenga una aplicacin web que invoque la clase Mates desde su index.jsp

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

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>

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 arrancndolo fuera de eclipse (dentro no va a funcionar!) Resuelto en MiSite.zip

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:
Cdigo heredado Convivencia con otros entornos de desarrollo que imponen sus propios modelos Etc.

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 ms nos interese tenerlo.

Para poder usarlo ser necesario:

1. Implementar el mojo como plugin de maven 2. Instalarlo en el repositorio local, o en uno de los remotos apuntados por nuestro POM. 3. Referenciarlo en el POM del proyecto que lo necesita usar para establecer la dependencia. 4. Configurarlo.

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:

Aadimos el jar de la distribucin 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 mtodo execute. Contenga el siguiente comentario de sintaxis javadoc a nivel de clase:

/** * Muestra mensajes de log * @goal 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-pluginapi:2.0

Listo! Instalamos el plugin y comprobamos que est bien subido al repositorio.

Ahora tenemos que entrar en el proyecto que tenemos empezado y establecer la dependencia del nuevo plugin para poder ejecutarlo.
<groupId>es.uniovi.si</groupId> <artifactId>log</artifactId>

<plugin>

</plugin>

Ya podemos ejecutarlo directamente sin necesidad de meterlo en el ciclo de vida, con la sintaxis:

mvn <groupId>:<artifactId>:<version>:<goal>

Tenemos un mojo dentro de un plugin que est dado de alta en nuestro proyecto. Podemos invocarlo explcitamente, pero ... cmo 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

Modificar el pom.xml del proyecto que tiene la dependencia del plugin y aadir lo siguiente:

<artifactId>log</artifactId> <executions> <execution> <phase>process-sources</phase> <goals> <goal>print</goal> </goals> </execution> </executions>

Los plugins necesitan informacin para poder realizar su cometido, de dos tipos:
Parmetros de configuracin que le pasemos cuando declaremos el plugin. Informacin relativa al ciclo de vida del proyecto (por ejemplo, directorios fuente.)

El paso de informacin a los plugins se realiza mediante una tcnica basada en inyeccin de dependencias un tanto especial.

Si queremos poder configurar parmetros del plugin, es necesario:

Crear un atributo privado para alojar el valor de configuracin 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. * * @parameter expression="HolaMundo" */ private String saludo;

Una vez tengamos el plugin preparado para recibir el parmetro, se lo hacemos llegar por medio del pom.xml.
<configuration> <saludo>Welcome</saludo> </configuration>

Porqu no hacemos una inicializacin Java? Dnde est el mtodo setter?

Extender el plugin log para que reciba un parmetro mensaje y sea ste el que imprima por pantalla. El parmetro estar inicializacon con la cadena Hola Mundo! (Resuelto en la versin 2 del piloto)

Maven permite utilizar expresiones para inicializar los parmetros 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 inicializacin de los parmetros valindose del lenguaje (no podra estipularse esto)

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

Completar el plugin para:

Aadir un parmetro artefacto de tipo Object al plugin Inicializarlo con la expresin que nos devuelve el nombre del artefacto. Extender el mtodo execute para que en el mensaje muestre tambin el valor de artefacto, invocando su mtodo toString(). (Resuelto en la versin 3.0)

Maven 2 tambin permite desarrollar plugins en ANT, lo cual facilita la reutilizacin de proyectos y la integracin con cdigo heredado. Para desarrollar un MOJO ANT en un plugin Maven 2, tendremos que facilitar:
La declaracin de la tarea en ANT que deseamos integrar para que Maven 2 la invoque. El descriptor del MOJO ANT.

Vamos a aadir 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 aadir ciertas dependencias al pom.xml del plugin:

<dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-script-ant</artifactId> <version>2.0.2</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.6.5</version> </dependency>

Y Finalmente, reconfigurar el plugin mavenplugin-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 E Intentar ejecutar el mojo que acabamos de crear.

mvn install

mvn es.uniovi.si:log:hola

Resultado:

... [INFO] [log:hola] saluda: [echo] Hola Mundo!!!! ...

Puede que en ciertas ocasiones necesitemos adaptar el proceso Maven a cdigo heredado. Por ejemplo: El cdigo fuente est alojado en la carpeta /src. Estos parmetros estn 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>

Supongamos que nuestro proyecto tiene los fuentes en la carpeta /src. Para cambiar este parmetro:
Sobrescribimos la propiedad sourceDirectory en la seccin 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.

Seguimos teniendo un problema: En el cdigo 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 seguira todo mezclado- queremos separar los fuentes antes de la compilacin, de forma que:
Las clases Test*.* se copien a la carpeta de Maven para pruebas Las dems, a la carpeta de fuentes

Creamos la carpeta /src con:

HolaMundo.java TestHolaMundo.java

Desarrollamos un plugin de ant para realizar la separacin de archivos y que cada tipo de clase se copie a su correspondiente ubicacin para que Maven compile lo que necesite. A qu fase lo vincularemos?