java - instalar - maven 4

¿Cómo se manejan las instantáneas maven-3 con marca de tiempo de manera eficiente? (6)

Agregue el siguiente parámetro en su archivo POM

POM

<configuration> <outputAbsoluteArtifactFilename>true</outputAbsoluteArtifactFilename> </configuration>

https://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html

Ejemplo de POM

<plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <version>2.10</version> <executions> <execution> <id>copy</id> <phase>package</phase> <goals> <goal>copy</goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <type>jar</type> <overWrite>false</overWrite> <outputDirectory>${project.build.directory}/alternateLocation</outputDirectory> <destFileName>optional-new-name.jar</destFileName> </artifactItem> </artifactItems> **<outputAbsoluteArtifactFilename>true</outputAbsoluteArtifactFilename>** <outputDirectory>${project.build.directory}/wars</outputDirectory> <overWriteReleases>false</overWriteReleases> <overWriteSnapshots>true</overWriteSnapshots> </configuration> </execution> </executions> </plugin> </plugins> </build>

Configurar en Jenkins:

// copy artifact copyMavenArtifact(artifact: "commons-collections:commons-collections:3.2.2:jar", outputAbsoluteArtifactFilename: "${pwd()}/target/my-folder/commons-collections.jar")

Ahora que maven-3 dejó de admitir el <uniqueVersion> false </ uniqueVersion> para los artefactos de instantáneas, parece que realmente necesita utilizar SNAPSHOTS con marcas de tiempo. Especialmente m2eclipse, que usa internamente maven 3, parece estar afectado, las instantáneas de actualización no funcionan cuando las SNAPSHOTS no son únicas.

Parecía una buena práctica antes establecer todas las instantáneas en uniqueVersion = false

Ahora, parece que no hay un gran problema para cambiar a la versión con marca de tiempo, después de todo están gestionados por un repositorio central de nexus, que es capaz de eliminar instantáneas viejas en intervalos regulares.

El problema son las estaciones de trabajo de desarrolladores locales. Su repositorio local rápidamente crece muy grande con instantáneas únicas.

¿Cómo lidiar con este problema?

Ahora mismo veo las siguientes soluciones posibles:

Pida a los desarrolladores que purguen el repositorio en intervalos regulares (lo que conduce a un montón de frustración, ya que lleva mucho tiempo eliminar e incluso más tiempo para descargar todo lo necesario)
Configure una secuencia de comandos que elimine todos los directorios SNAPSHOT del repositorio local y solicite a los desarrolladores que ejecuten esa secuencia de comandos de vez en cuando (mejor que la primera, pero que aún lleva bastante tiempo ejecutar y descargar las instantáneas actuales)
use el plugin de dependencia: purge-local-repository (Tiene problemas cuando se ejecuta desde eclipse, debido a archivos abiertos, debe ejecutarse desde cada proyecto)
configurar nexus en cada estación de trabajo y configurar un trabajo para limpiar instantáneas antiguas (mejor resultado, pero no quiero mantener más de 50 servidores nexus, además de que la memoria siempre está ajustada en las estaciones de trabajo de los desarrolladores)
deja de usar SNAPSHOTS en absoluto

¿Cuál es la mejor manera de evitar que su repositorio local llene su espacio en el disco duro?

Actualizar:

Para verificar el comportamiento y para dar más información configuro un pequeño servidor nexus, construyo dos proyectos (ayb) e intento:

un:

segundo:

<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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>de.glauche</groupId> <artifactId>b</artifactId> <version>0.0.1-SNAPSHOT</version> <distributionManagement> <snapshotRepository> <id>nexus</id> <name>nexus</name> <url>http://server:8081/nexus/content/repositories/snapshots/</url> </snapshotRepository> </distributionManagement> <repositories> <repository> <id>nexus</id> <name>nexus</name> <snapshots> <enabled>true</enabled> </snapshots> <url>http://server:8081/nexus/content/repositories/snapshots/</url> </repository> </repositories> <dependencies> <dependency> <groupId>de.glauche</groupId> <artifactId>a</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies> </project>

Ahora, cuando uso maven y ejecuto "deploy" en "a", tendré

a-0.0.1-SNAPSHOT.jar a-0.0.1-20101204.150527-6.jar a-0.0.1-SNAPSHOT.pom a-0.0.1-20101204.150527-6.pom

en el repositorio local. Con una nueva versión de marca de tiempo cada vez que ejecuto el objetivo de despliegue. Lo mismo ocurre cuando trato de actualizar las instantáneas del servidor nexus (cierre "a" Project, elimínelo del repositorio local, construya "b")

En un entorno donde se construyen muchas instantáneas (piense en el servidor hudson ...), el repositorio local se llena rápidamente de versiones antiguas.

Actualización 2:

Para probar cómo y por qué esto está fallando hice algunas pruebas más. Cada prueba se ejecuta contra todo limpio (de / glauche se elimina de ambas máquinas y del nexo)

mvn deploy con maven 2.2.1:

el repositorio local en la máquina A contiene snapshot.jar + snapshot-timestamp.jar

PERO: solo un jar con marca de tiempo en el nexo, los metadatos dicen:

<?xml version="1.0" encoding="UTF-8"?> <metadata> <groupId>de.glauche</groupId> <artifactId>a</artifactId> <version>0.0.1-SNAPSHOT</version> <versioning> <snapshot> <timestamp>20101206.200039</timestamp> <buildNumber>1</buildNumber> </snapshot> <lastUpdated>20101206200039</lastUpdated> </versioning> </metadata>

Ejecutar dependencias de actualización (en la máquina B) en m2eclipse (m3 final incrustado) -> repositorio local tiene snapshot.jar + snapshot-timestamp.jar :(
ejecutar el objetivo del paquete con maven externo 2.2.1 -> repositorio local tiene snapshot.jar + snapshot-timestamp.jar :(

Ok, luego intenta con maven 3.0.1 (después de eliminar todos los rastros del proyecto a)

el repositorio local en la máquina A se ve mejor, solo uno que no tiene marca de tiempo
solo un jar con marca de tiempo en el nexo, los metadatos dicen:
de.glauche a 0.0.1-SNAPSHOT
<snapshot> <timestamp>20101206.201808</timestamp> <buildNumber>3</buildNumber> </snapshot> <lastUpdated>20101206201808</lastUpdated> <snapshotVersions> <snapshotVersion> <extension>jar</extension> <value>0.0.1-20101206.201808-3</value> <updated>20101206201808</updated> </snapshotVersion> <snapshotVersion> <extension>pom</extension> <value>0.0.1-20101206.201808-3</value> <updated>20101206201808</updated> </snapshotVersion> </snapshotVersions>
Ejecutar dependencias de actualización (en la máquina B) en m2eclipse (m3 final incrustado) -> repositorio local tiene snapshot.jar + snapshot-timestamp.jar :(
ejecutar el objetivo del paquete con maven externo 2.2.1 -> repositorio local tiene snapshot.jar + snapshot-timestamp.jar :(

Entonces, para recapitular: el objetivo de "implementación" en maven3 funciona mejor que en 2.2.1, el repositorio local en la máquina creadora se ve bien. Pero, el receptor siempre termina con muchas versiones de tiempos ...

Qué estoy haciendo mal ?

Actualización 3

También probé varias otras configuraciones, primero reemplazo nexus con artefactory -> mismo comportamiento. A continuación, utilice los clientes de linux maven 3 para descargar las instantáneas desde el administrador de repositorios -> el repositorio local todavía tiene instantáneas con marca de tiempo :(

Bueno, no me gustaron las soluciones propuestas. La eliminación de caché maven a menudo aumenta significativamente el tráfico de red y ralentiza el proceso de compilación. build-helper-maven-plugin ayuda solo con un artefacto, quería una solución que pueda purgar todos los artefactos desactualizados de instantáneas de la memoria caché local en un solo comando. Después de unos días de búsqueda, me di por vencido y decidí escribir un programa pequeño. El programa final parece estar funcionando bastante bien en nuestro entorno. Así que decidí compartirlo con otras personas que puedan necesitar esa herramienta. Las fuentes se pueden extraer de github: https://github.com/nadestin/tools/tree/master/MavenCacheCleanup

En cuanto a la parte del repositorio remoto de esto, creo que las respuestas previas que discuten una depuración de SNAPSHOTs en un intervalo regular funcionarán. Pero nadie ha abordado la parte de la sincronización de la estación de trabajo de desarrollador local de su pregunta.

Todavía no hemos empezado a utilizar Maven3, por lo que todavía tenemos que ver SNAPSHOTs comenzando a acumularse en las máquinas locales.

Pero hemos tenido diferentes problemas con m2eclipse. Cuando tenemos habilitada la "Resolución de espacio de trabajo" y el proyecto existe dentro de nuestro espacio de trabajo, las actualizaciones de fuentes usualmente nos mantienen al borde del desastre. Pero descubrimos que es muy difícil conseguir que m2eclipse se actualice con artefactos publicados recientemente en Nexus. Estamos experimentando problemas similares dentro de nuestro equipo y es particularmente problemático porque tenemos un gráfico de proyecto muy grande ... hay muchas dependencias que no estarán en su espacio de trabajo, pero que recibirán SNAPSHOTs con frecuencia.

Estoy bastante seguro de que esto se reduce a un problema en m2eclipse donde no maneja SNAPSHOT exactamente como debería. Puedes ver en la consola de Maven dentro de eclipse donde m2eclipse te dice que se está saltando la actualización de una SNAPSHOT recientemente publicada porque tiene una versión en caché. Si realiza una -U desde una configuración de ejecución o desde la línea de comando, Maven recuperará el cambio de metadatos. Pero una selección de "Actualizar instantáneas ..." debería decirle a m2eclipse que Maven expire este caché. No parece ser pasado de largo. Parece que hay un error por el que se presenta para esto si le interesa votar: https://issues.sonatype.org/browse/MNGECLIPSE-2608

Hiciste mención de esto en un comentario en alguna parte.

La mejor solución para este problema parece ser hacer que los desarrolladores purguen sus estaciones de trabajo locales cuando las cosas empiezan a descomponerse dentro de m2eclipse. Solución similar a un problema diferente ... Otros han informado de problemas con Maven 2.2.1 y 3 de respaldo de m2eclipse, y he visto lo mismo.

Espero que si está usando Maven3, puede configurarlo para que solo saque la última SNAPSHOT, y la guarde en caché por el tiempo que dure el repositorio (o hasta que lo expire a mano). Con suerte, entonces no necesitará tener un montón de SNAPSHOTs en su repositorio local.

Eso es a menos que esté hablando de un servidor de compilación que está haciendo manualmente una mvn install en ellos. En cuanto a cómo evitar que SNAPSHOTs se acumule en un entorno como un servidor de compilación, hemos eludido esa bala haciendo que cada compilación use su propio espacio de trabajo y repositorio local (aunque en Maven 2.2.1, ciertas cosas como Los POM parecen salir siempre del ~ / .m2 / repositorio). Las SNAPSHOT adicionales solo se quedan en una única compilación y luego se descartan (y se vuelven a descargar desde cero). Así que hemos visto que este enfoque termina consumiendo más espacio para empezar, pero tiende a permanecer más estable que tener todo resuelto de un único repositorio. Esta opción (en Hudson) se llama "Usar repositorio Maven privado" y está debajo del botón Avanzado de la sección Generar en las configuraciones del proyecto cuando seleccionó construir con Maven. Aquí está la descripción de la ayuda para esa opción:

Normalmente, Hudson usa el repositorio Maven local según lo determine Maven: el proceso exacto parece no documentarse, pero es ~ / .m2 / repository y puede anularse en ~ / .m2 / settings.xml (consulte la referencia para obtener más detalles). .) Esto normalmente significa que todos los trabajos que se ejecutan en el mismo nodo comparten un único repositorio de Maven. La ventaja de esto es que puede ahorrar espacio en el disco, pero la desventaja de esto es que a veces esas compilaciones pueden interferir entre sí. Por ejemplo, puede que las compilaciones tengan un éxito incorrecto, simplemente porque tiene todas las dependencias en su repositorio local, a pesar de que ninguno de los repositorios en POM podría tenerlas.
También hay algunos problemas informados con respecto a tener procesos de Maven simultáneos que intentan usar el mismo repositorio local.
Cuando esta opción está marcada, Hudson le indicará a Maven que use $ WORKSPACE / .repository como el repositorio local de Maven. Esto significa que cada trabajo obtendrá su propio repositorio Maven aislado solo para sí mismo. Soluciona los problemas anteriores, a expensas del consumo de espacio de disco adicional.
Cuando use esta opción, considere configurar un administrador de artefactos Maven para que no tenga que golpear depósitos remotos de Maven con demasiada frecuencia.
Si prefiere activar este modo en todos los trabajos de Maven ejecutados en Hudson, consulte la técnica que se describe aquí.

Espero que esto ayude; si no resuelve tu problema, avísame dónde me he perdido.

Este complemento elimina los artefactos del proyecto del repositorio local. Útil para mantener solo una copia de una instantánea local grande.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.7</version> <executions> <execution> <id>remove-old-artifacts</id> <phase>package</phase> <goals> <goal>remove-project-artifact</goal> </goals> <configuration> <removeAll>true</removeAll> </configuration> </execution> </executions> </plugin>

La configuración de <uniqueVersion> aplica a los artefactos que se implementaron (a través de mvn deploy) en un repositorio de Maven como Nexus.

Para eliminar estos de Nexus, puede crear fácilmente un trabajo automatizado para purgar el repositorio de SNAPSHOT todos los días. Se puede configurar para retener un cierto número de instantáneas o mantenerlas durante un cierto período de tiempo. Es súper fácil y funciona genial.

Los artefactos en el repositorio local en una máquina de desarrollador llegan desde el objetivo de "instalación" y no usan estas marcas de tiempo ... simplemente siguen reemplazando la única versión SNAPSHOT a menos que también incremente el número de revisión (por ejemplo, 1.0.0- SNAPSHOT a 1.0.1-SNAPSHOT).

En groovy , eliminar archivos con marcas de tiempo como artifact-0.0.1-20101204.150527-6.jar puede ser muy simple:

root = ''path to your repository'' new File(root).eachFileRecurse { if (it.name.matches(/.*/-/d{8}/./d{6}/-/d+/.[/w/.]+$/)) { println ''Deleting '' + it.name it.delete() } }

Instale Groovy , guarde la secuencia de comandos en un archivo y programe la ejecución en cada semana, inicie, inicie sesión, lo que más le convenga.

O bien, puede cablear la ejecución en maven build, usando gmavenplus-plugin . Observe cómo es la ubicación del repositorio establecida por maven en la propiedad settings.localRepository y luego enlazada a través de la configuración en el repository variables:

<plugin> <groupId>org.codehaus.gmavenplus</groupId> <artifactId>gmavenplus-plugin</artifactId> <version>1.3</version> <executions> <execution> <phase>install</phase> <goals> <goal>execute</goal> </goals> </execution> </executions> <configuration> <properties> <property> <name>repository</name> <value>${settings.localRepository}</value> </property> </properties> <scripts> <script><![CDATA[ new File(repository).eachFileRecurse { if (it.name.matches(/.*/-/d{8}/./d{6}/-/d+/.[/w/.]+$/)) { println ''Deleting snapshot '' + it.getAbsolutePath() it.delete() } } ]]></script> </scripts> </configuration> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>2.3.7</version> <scope>runtime</scope> </dependency> </dependencies> </plugin>