Inicio > Comandos Linux, Maven > Modificar path del déposito maven: -Dmaven.repo.local

Modificar path del déposito maven: -Dmaven.repo.local

16 diciembre, 2013 Deja un comentario Go to comments

Cuando trabajamos con Maven, utilizamos algo que se llaman repositories o depósitos. Estos depósitos contienen los artifactos que un proyecto necesita para compilar y ejecutarse. Ellos corresponden a los jar de las dependencias del proyecto que definimos en el archivo pom.xml, del cual se hablo un poco aquí. Para mas información sobre lo qué es un depósito, ver acá.

El objetivo de estos depósitos es que cuando compilamos un proyecto, podamos recuperar los artifactos de nuestras dependecias y guardarlos en nuestra máquina de manera a reutilizarlos sin necesidad de descargarlos desde un depósito remoto como un Nexus en Jenkins. De esta manera, recuperamos artifactos de librerias comunes entre proyectos como commmons.io, commons.collections, etc. Esas dependecias son especificadas en el pom.xml del proyecto. Consideremos el siguiente ejemplo:

<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>com.jomaora.app</groupId>
____<artifactId>testMockito</artifactId>
____<packaging>jar</packaging>
____<version>1.5-SNAPSHOT</version>
____<name>testMockito</name>
____<build>
________<plugins>
____________<plugin>
________________<groupId>org.apache.maven.plugins</groupId>
________________<artifactId>maven-compiler-plugin</artifactId>
________________<version>2.3.2</version>
________________<configuration>
____________________<source>1.6</source>
____________________<target>1.6</target>
________________</configuration>
____________</plugin>
________</plugins>
____</build>
____<dependencies>
________<dependency>
____________<groupId>com.jomaora.app</groupId>
____________<artifactId>myproject</artifactId>
____________<version>${project.version}</version>
________</dependency>
________<dependency>
____________<groupId>com.google.guava</groupId>
____________<artifactId>guava</artifactId>
____________<version>${guava.version}</version>
________</dependency>
________<dependency>
____________<groupId>org.mockito</groupId>
____________<artifactId>mockito-core</artifactId>
____________<version>${mockito.version}</version>
________</dependency>
____</dependencies>
____<properties>
________<mockito.version>1.9.0</mockito.version>
________<guava.version>11.0.1</guava.version>
____</properties>
</project>

Cuando compilamos el proyecto (mvn clean install), las dependencias se alojan por defecto en el directorio oculto m2 de la HOME del usuario. Es fácil ubicarlas si uno lee el pom.xml. En el caso de mockito, el pom indica el groupId y el artifact que nos sirven para el path hacia el archivo, asi como la versión en la 1.9.0.

reposiroty

Ahora bien. Supongamos que tenemos dos equipos estan trabajando en evoluciones importantes sobre myproject. El equipo A trabaja en la rama (branch) dev-1.5 y el equipo B trabaja en la rama dev-1.5-big-improuvement. El equipo A tiene una fecha de entrega prevista antes que el equipo B, y tanto el equipo A como el equipo B trabajan sobre la misma máquina para hacer sus pruebas (he aquí el detalle importante del asunto).

El problema que esto presenta es que cada vez que myprojet será compilado por un equipo, el artifacto generado va a reemplazar al del otro equipo. Ejemplo:

  1. El equipo B compila el proyecto desde su rama (dev-1.5-big-impouvement) con mvn clean install, el jar de myproject se actualiza en el depósito. Luego el equipo B empaqueta la aplicación que utiliza myproject (mvn clean package) y entonces el artifacto se recupera desde el depósito.
  2. El equipo A compila el proyecto desde su branch (dev-1.5), y el jar de my project se actualiza en el depósito, reemplazando el generado por el equipo B. Problema, este nuevo artifacto no contiene los commits de la branch (dev-1.5-big-impouvement).
  3. Sin saberlo, el equipo B repite el empaquetado de la aplicación. Como el artifacto de myproject no es re compilado, la versión generada por el equipo A es recuperada y la aplicación no tendrá las modificaciones del equipo B.

Capture du 2013-11-22 18:00:00

Para evitar este problema, lo mejor es utilizar un depósito diferente para cada equipo, hasta que todas las ramas sean fusionadas (merge) en la rama a entregar. Para ello, el comando mvn de maven tiene un parámetro que permite indicar el directorio que nos servirá de depósito temporal: -Dmaven.repo.local. Ejemplo:

mvn clean install -Dmaven.repo.local=/usr/local/web/.m2/repository-equipoB 

  1. Aún no hay comentarios.
  1. No trackbacks yet.

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

Hype Driven Development

coz' geeks love new stuff !

My experiments with SCRUM

Site to discuss Agile (Scrum, XP, etc) concepts and ideas.

CommitStrip

Mi propia cheatsheet...

Chris Aniszczyk's (zx) diatribe

work. life. open source. diatribes.

GermanTrevi

repositorio de mi mente...

A %d blogueros les gusta esto: