Mejores prácticas con Maven

26/03/2015

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.


* Minimiza el número de dependencias SNASPHOT

Está estrictamente NO recomendado el uso de versiones SNAPSHOT en las dependencias de tu proyecto ya que nunca garantiza que una versión SNAPSHOT esté disponible en cualquier repositorio. Esto puede derivar en los errores de construcción bien conocidos por dependencias no encontradas. Así que para proyectos que “no te pertenezcan”… es preferible utilizar versiones reales.

Cómo detectar si tienes una versión SNAPSHOT.

* Utiliza la sección de gestión de dependencias

La transitividad de dependencias es una gran característica… pero al final quieres estar seguro de la versión que usas y envías a producción.

La gestión de dependencias te permite consolidar y centralizar la gestión de las versiones de las dependencias sin añadir dependencias que son heredadas por todos los hijos. Esto es especialmente útil cuando tienes un conjunto de proyectos (esto es, más de uno) que heredan de un padre común.

Otro caso de uso de dependencyManagement extremadamente importante es el control de versiones de los artefactos utilizado en la dependencias transitivas. Esto es difícil de explicar sin un ejemplo. Afortunadamente, esto está ilustrado en la documentación.

	
    <dependencyManagement>
        <dependencies>
                 ...

* Preocúpate de la reubicación en el repositorio maven

Reubicar un artefacto es cambiar el “id maven” (groupId:artifactId) de un proyecto.


xstream:xstream
com.thoughtworks.xstream:xstream

Una trampa común en la reubicación maven es tener jars dobles incluso en la correcta utilización de dependencyManagement.

Utiliza el m2eclipse y sus vista de jerarquía de dependencias, para detectar y excluir los artefactos no deseados.

* Después de modificar una dependencia, comprueba los artefactos producidos

Un hábito saludable consiste en comprobar tu war/ear producido después de añadir una nueva dependencia o de actualizar una existente.

Dos buenas herramientas para ayudarte en esto son:

USA Y ABUSA DE LOS MÓDULOS

Los módulos pueden ser más “técnicos”

<modules>
  <module>mymodule_api</module> <!-- service interface, value objects, exception -->
  <module>mymodule_impl</module> <!-- service & dao implementation -->
  <module>mymodule_web</module> <!-- web components, controllers, templates.. -->
</modules>

o

Más orientados a “negocio”

	
<modules>
   <module>contract_modules</module>
   <module>finance_modules</module>
   <module>time_modules</module>
   <module>agenda_modules</module>
</modules>

HAZ LA CONSTRUCCIÓN MANTENIBLE

* Preferentemente usa la estructura de directorios por defecto

Esto hará la configuración de los plugins más sencilla:

src/main/java         Fuentes de aplicación/librería
src/main/resources    Recursos de aplication/librería
src/main/webapp       Recursos de aplicación Web (para el empaquetado war)
src/test/java         Fuentes de pruebas
src/test/resources    Recursos de pruebas

* Evita la duplicidad moviendo etiquetas comunes al pom padre

¿De verdad quieres tener que decir que compilas para la jrk 1.5 en todos tus proyectos?

	
    <!-- Use Java 1.5 -->
    <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>2.3.1</version>
       <configuration>
            <fork>${javacFork}</fork>
            <executable>${javacExecutable}</executable>
            <verbose>${javacVerbose}</verbose>
            <compilerVersion>${jdk.version}</compilerVersion>
            <source>${jdk.version}</source>
            <target>${jdk.version}</target>
        </configuration>
    </plugin>

¡muévelo a un pom padre!

por ejemplo, en

  corporate_base_pom  ->  app_basecom  ->       app_module1         -> app_sub_modules

    jdk 1.5               dependencias          dependencias                    
 repo empresarial           técnicas            de aplicación
                           (spring,...)         (app_module2,app_module3,..)

* Especifica siempre una versión de dependencias en un pom padre

Prefiere un lugar central para la definición de versiones.
No especifiques versiones un un sub-módulo específico.

* Utiliza properties con total libertad

Agrupa dependencias con properties… para evitar copiar/pegar la versión en todas partes y ayudar a la fácil actualización de versión.

Y muévelo a un pom padre.

	
<properties>
    <spring.version>3.0.0.RELEASE</spring.version>
</properties>
 
<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-webmvc</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-jdbc</artifactId>
        <version>${spring.version}</version>
    </dependency>
</dependencies>

* Minimiza el número de perfiles

Los perfiles puede ayudar mucho… pero inevitablemente complicarán el proceso.
Así que no añadas perfiles si por ejemplo añadiendo un nuevo proyecto con un ensamblado conseguiría el objetivo. Maven Profile Best Practices

  • La construcción se debe poder realizar cuando no se ha activado ningún perfil
  • Utiliza perfiles para adaptarte a contextos en tiempo de construcción, no contextos en tiempo de ejecución, y no (salvo raras excepciones) para producir versiones alternativas de tu arterfacto

Recuerda: El soporte para perfiles fuera del POM o settings.xml ha sido eliminado en Maven 3.x.

HAZ LA CONSTRUCCIÓN PORTABLE

* No hagas commit de artefactos eclipse y maven

Para simplificar el checkout… evita hacer commit de los siguientes ficheros y directorios


.project
.classpath
.settings
.wtpmodules
target

estos ficheros generalmente:

  • referencias configuraciones locales como nombre/paths de la JRE..
  • son específicos de una versión de plugins (wtp,…)

así que deja que m2eclipse los gestiones y mantenga/genere el .project, .classpath,…

ver Subversion and the importance of svn:ignore for MAVEN multi modules

* No modifiques pom/artefactos en tu repositorio “empresarial”

Siempre es una tentación el arreglar un pom o un jar en el repositorio central… no lo hagas.
Identifícalo como una versión especial en tu repositorio “artefact-1.0.5.corporatepath” o gestiona las exclusiones correctas.

ver Maven doesn’t suck, your POM does

vía

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: