Vamos a explicar lo qué es un plugin y los diferentes plugins que se han generado en nuestro proyecto, para hacernos un poco a la idea.
Maven para realizar cualquier tarea (compilación, despliegues, etc) se basa en plugins. Un plugin podríamos definirlo como una de aquellas tareas predefinidas que veíamos en ant, que realizan una acción.
Por ejemplo, si quisieramos compilar nuestro proyecto, el plugin encargado de realizar esta tarea sería el Maven Compiler plugin.
Si quisieramos desplegar en un WebLogic, nuestro proyecto, probablemente usaríamos el WebLogic Development Maven Plug-In.
En Maven existen dos tipos de plugins:
- Build plugins: Son aquellos que se ejecutarán durante la construcción del artefacto. (Van a ser los que nos vamos a encontrar en el ejemplo que estamos tratando).
- Reporting plugins: Son aquellos que se ejecutarían en la generación de documentación del sitio (mvn site), y que en general generan informes en PDF acerca de las dependencias, despliegues, etc (Ejemplo).
Pero antes de continuar profundizando en los plugins y viendo cómo hace uso Maven de ellos, tenemos que entender cúal es la filosofía que emplea Maven en la generación de proyectos.
Por defecto, Maven tiene tres ciclos de vida predefinidos (nosotros, podemos crear otros, pero por lo general nos basta):
- default: el ciclo de vida por defecto, que aglutina las siguientes fases:
- validate: valida que se tiene toda la información para comenzar el ciclo.
- compile: compila el código del proyecto.
- test: lanza los tests unitarios.
- package: empaqueta el código (por ejemplo en un Jar).
- integration-test: despliega en un entorno de integración y lanza los tests de integración.
- verify: verifica que el paquete es correcto
- install: instala el artefacto en el repositorio local de maven
- deploy: despliega el paquete en un repositorio remoto que indiquemos (Ej:Nexus) para que esté disponible para el resto de desarrolladores.
- clean: limpia el proyecto
- site: genera la documentación del proyecto.
(En el ciclo default se han mostrado las más importantes, si se quieren ver todas las fases intermedias se pueden consultar aquí).
Cada plugin que insertemos dentro de la construcción de nuestro proyecto, debe estar asociado a una de estas fases (validate, compile..., etc).
La manera de ejecutar el ciclo de vida a través del terminal es muy simple. Si queremos que se ejecute una limpieza de proyecto y se compile (si le pedimos a Maven que ejecute la fase compile, ejecutará también las anteriores, en este caso validate) ejecutaremos:
La manera de ejecutar el ciclo de vida a través del terminal es muy simple. Si queremos que se ejecute una limpieza de proyecto y se compile (si le pedimos a Maven que ejecute la fase compile, ejecutará también las anteriores, en este caso validate) ejecutaremos:
mvn clean compile
Si deseamos generar los empaquetados del proyecto (sin limpiar el proyecto), ejecutaríamos:
mvn package
Si quisieramos limpiar el proyecto y realizar todo el ciclo de vida, ejecutaríamos:
mvn clean deploy
Nos indica un error de que no hemos declarado ningún repositorio remoto donde almacenar el paquete (lo que sería un servidor Nexus dónde subir nuestros propios artefactos).
Echemos un vistazo a nuestro pom.xml que obtuvimos en la anterior entrada y veamos qué plugins traía el arquetipo con el que generamos nuestro servicio Rest con Apache CXF y Spring.
Lo primero que deberíamos ver, es que solo hay plugins de tipo build, que no tenemos declarado ningún plugin que genere documentación.
Lo siguiente que debería sorprendernos es que hay dos secciones dentro de <build>:
- pluginManagement: Aquí se definen los plugins que heredaran los módulos de los que conste el proyecto (en nuestro ejemplo, no tenemos hijos, pero en entradas posteriores veremos un ejemplo de proyecto padre con submódulos).
- plugins: Aquí se definen el resto de plugins que afectan solo a este artefacto en particular (no a sus hijos).
A continuación vamos explicando los diferentes plugins en orden de aparición (si se tiene curiosidad por ver más, aquí podemos ver una lista de los que trae maven por defecto).
<plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.0</version> <executions> <execution> <id>default-cli</id> <goals> <goal>run</goal> </goals> <configuration> <port>13000</port> <path>/jaxrs-service</path> <useSeparateTomcatClassLoader>true</useSeparateTomcatClassLoader> </configuration> </execution> </executions> </plugin>Se encarga de desplegar en el puerto 13000 y en el contexto /jaxrs-service un tomcat7 con el proyecto. (Más documentación)
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin>
Se encarga de compilar el proyecto para que sea compatible con la versión 1.6 de Java. (Más documentación)
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-eclipse-plugin</artifactId> <configuration> <projectNameTemplate>[artifactId]-[version]</projectNameTemplate> <wtpmanifest>true</wtpmanifest> <wtpapplicationxml>true</wtpapplicationxml> <wtpversion>2.0</wtpversion> </configuration> </plugin>Se encarga de que el proyecto sea compatible con Eclipse, para lo que genera los diferentes ficheros de configuración que son necesarios. (Más documentación)
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.5</version> <executions> <execution> <id>reserve-network-port</id> <goals> <goal>reserve-network-port</goal> </goals> <phase>process-test-resources</phase> <configuration> <portNames> <portName>test.server.port</portName> </portNames> </configuration> </execution> </executions> </plugin>Se encarga de buscar un puerto libre en el sistema y asignárselo a la variable test.server.port en la fase process-test-resources (después de compilar cuando se preparan los tests). Este plugin además permite otras muchas tareas, como podemos consultar en su documentación.
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<executions>
<execution>
<id>start-tomcat</id>
<goals>
<goal>run-war</goal>
</goals>
<phase>pre-integration-test</phase>
<configuration>
<port>${test.server.port}</port>
<path>/jaxrs-service</path>
<fork>true</fork>
<useSeparateTomcatClassLoader>true</useSeparateTomcatClassLoader>
</configuration>
</execution>
<execution>
<id>stop-tomcat</id>
<goals>
<goal>shutdown</goal>
</goals>
<phase>post-integration-test</phase>
<configuration>
<path>/jaxrs-service</path>
</configuration>
</execution>
</executions>
</plugin>
Se encarga de arrancar el tomcat antes de lanzar los test de integración y pararlo al acabar (fases pre-integration-test y post-integration-test) (Misma documentación que para la tarea de pluginManagement).<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.8.1</version>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
<configuration>
<systemPropertyVariables>
<service.url>http://localhost:${test.server.port}/jaxrs-service</service.url>
</systemPropertyVariables>
</configuration>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
Se encarga de la ejecución de los test de integración (Más documentación)Conclusión:
Es normal que si es la primera vez que nos acercamos ahora mismo nos sintamos un poco perdidos. Lo más importante es tener claro el concepto de las diferentes fases del ciclo de vida por defecto y comprender el concepto de plugin (entendiendo por encima qué es lo que hace cada uno).
En la próxima entrega jugaremos un poco más con los plugins para que paso a paso, veamos como añadir nuevos plugins a nuestro proyecto y ejecutarlos.
No hay comentarios:
Publicar un comentario