MAVEN Lifecycle

10/06/2016

Maven

Fundamentos básicos del ciclo de vida de la construcción

Maven se fundamenta en el concepto central de ciclo de vida de construcción (build lifecycle). Esto significa que el proceso de construcción y distribución de un artifact (artefacto = proyecto) concreto está definido claramente.

Para la persona que quiera construir un proyecto significa que solamente es necesario aprender un pequeño conjunto de comandos para construir cualquier proyecto Maven, y el POM se asegurará de que obtenga los resultados deseados.

Existen tres ciclos de vida en el sistema: default, clean y site. El ciclo de vida default controla el despliegue de tu proyecto, el ciclo de vida clean controla la limpieza de tu proyecto, mientras que el ciclo de vida site controla la creación del site de documentación de tu proyecto.

Leer el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Construir y probar
  • Subir el cambio de versión de desarrollo al SCM

Bastante sencillo, no?

Leer el resto de esta entrada »

Maven

Para conseguir nuestro objetivo debemos seguir una serie de pasos:

  • Obtener el código fuente tal cual está
  • Asociarle una versión (probablemente eliminado el subfijo -SNAPSHOT) de modo que pueda ser identificado unívocamente
  • Construir y probar
  • Etiquetar este estado en el SCM para que pueda ser asociado con el artefacto correspondiente
  • Asociar una nueva versión de desarrollo (probablemente subiendo el número de versión y añadiendo el subfijo -SNAPSHOT)
  • Subir el cambio de versión de desarrollo al SCM
  • Obtener el código fuente de la versión etiquetada
  • Construir, probar y empaquetar
  • Desplegar en un repositorio de artefactos donde pueda ser recuperado para su instalación

Bastante sencillo, no?

Leer el resto de esta entrada »

Maven

Si alguna vez has trabajado con Maven sabrás que te permite definir propiedades personalizadas que se pueden utilizar como placeholders (marcadores o comodines) para reutilizar valores o con fines de configuración o incluso como un modo de configurar los recursos de tu construcción final usando filtros (filters).  Esto nos viene muy bien para definir configuraciones específicas por entorno.

Estas propiedades personalizadas se pueden definir en múltiples lugares.  Pero ¿qué ocurre cuando defines (o re-defines) la misma propiedad en múltiples lugares?  ¿Que definición tendrá precedencia sobre las otras?

El orden de precedencia a la hora de resolver el valor de las propiedades personalizadas en Maven es el siguiente:

  • Propiedades del sistema (system):  establecidas con -Dxyz=valor desde la línea de comandos
  • De/los perfil/es (profile) activo/s actualmente:  settings.xml del directorio de usuario primero, profiles.xml del directorio raiz del proyecto después, y los perfiles definidos en el pom.xml en último lugar.  Si están activos varios perfiles y una propiedad está definida en más de uno, el orden de precedencia se basa en el último perfil en que la propiedad ha sido definido, en orden alfabético del nombre del perfil.
  • En la sección properties del pom.xml
  • Por último, en los properties de los filtros.  Si una propiedad se define en múltiples filtros, el último (en orden de aparición en la sección filters) tiene precedencia sobre los otros.

vía

tattletale_logo_600px
¿Alguna vez te has encontrado un problema al ejecutar tu aplicación web porque varios de los ficheros jar incluidos tienen las mismas clases en diferentes versiones y la que coge el servidor de aplicaciones es la incorrecta?

Utilizando la herramienta Tattletale de JBoss y su plugin Maven, puedes encontrar fácilmente si tienes clases duplicadas en la carpeta WEB-INF/lib de tu WAR y más importante, hacer que falle la construcción automáticamente si eso ocurre, de modo que no sea demasiado tarde y te ocurra en producción.

Simplemente añade la siguiente configuración del plugin en el pom de tu WAR, en la sección build/plugins. También se puede utilizar en EAR, assemblies y otros tipos de proyectos.

	
<plugin>
  <groupId>org.jboss.tattletale</groupId>
  <artifactId>tattletale-maven</artifactId>
  <version>1.1.2.Final</version>
  <executions>
    <execution>
      <phase>verify</phase> <!-- needs to run after WAR package has been built -->
      <goals>
        <goal>report</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <source>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</source>
    <destination>${project.reporting.outputDirectory}/tattletale</destination>
    <reports>
      <report>jar</report>
      <report>multiplejars</report>
    </reports>
    <profiles>
      <profile>java6</profile>
    </profiles>
    <failOnWarn>true</failOnWarn>
    <!-- excluding some jars, if jar name contains any of these strings it won't be analyzed -->
    <excludes>
      <exclude>persistence-api-</exclude>
      <exclude>xmldsig-</exclude>
    </excludes>
  </configuration>
</plugin>

Tendrás que añadir el repositorio Maven de JBoss a la sección repositories de tu POM, o a tu gestor de repositorios. Asegúrate de utilizar el repositorio que solamente contiene artefactos JBoss o podrías experimentar conflictos entre artefactos en ese repositorio y el repositorio Central de Maven.

<repository>
  <id>jboss</id>
  <url>https://repository.jboss.org/nexus/content/repositories/releases</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>

Nota: Añadir repositorios extra es una fuente común de problemas que provoca construcciones más lentas (se consulta todos los repositorios en busca de artefactos).

vía

Maven
HAZ LA CONSTRUCCIÓN REPRODUCIBLE

* Especifica siempre una versión de los plugins Maven2
Modo incorrecto

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
</plugin>

Modo correcto

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
 <version>2.3</version>
 </plugin>

Esto importa porque si no pones la versión, maven2 utiliza por defecto la ULTIMA disponible.

Esto quiere decir que

  • el resultado del plugin puede ser impredecible si la implementación ha cambiado (características nuevas/eliminadas, …)
  • tu proyecto, sin saberlo, se convierte automáticamente en un beta-tester para plugins de terceros si la última versión es una SNAPSHOT

Las nuevas versiones de m2eclipse mostrarán una advertencia en la consola. Puede revisar también el plugin enforcer de maven.

Leer el resto de esta entrada »

m2eclipse
Esta posibilidad está disponible bajo el menú Import.

Por ejemplo, pulsa el botón derecho en una fichero jar de tu workspace, selecciona Import –> Maven –> Install or deploy an artifact to a Maven repository.

vía

A %d blogueros les gusta esto: