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

Ahora que maven-3 dejó de admitir el false 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 repository 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 repository 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 repository 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 repository 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 repository 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 bash:

un:

 4.0.0 de.glauche a 0.0.1-SNAPSHOT   nexus nexus http://server:8081/nexus/content/repositories/snapshots    

segundo:

  4.0.0 de.glauche b 0.0.1-SNAPSHOT   nexus nexus http://server:8081/nexus/content/repositories/snapshots/     nexus nexus  true  http://server:8081/nexus/content/repositories/snapshots/     de.glauche a 0.0.1-SNAPSHOT    

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 repository local. Con una nueva versión de marca de tiempo cada vez que ejecuto el objective de despliegue. Lo mismo ocurre cuando trato de actualizar las instantáneas del servidor nexus (cierre “a” Project, elimínelo del repository local, construya “b”)

En un entorno donde se construyen muchas instantáneas (piense en el servidor hudson …), el repository 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 repository 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:

   de.glauche a 0.0.1-SNAPSHOT   20101206.200039 1  20101206200039   
  • Ejecutar dependencias de actualización (en la máquina B) en m2eclipse (m3 final incrustado) -> repository local tiene snapshot.jar + snapshot-timestamp.jar 🙁
  • ejecutar el objective del paquete con maven externo 2.2.1 -> repository 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 repository 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

      20101206.201808 3  20101206201808   jar 0.0.1-20101206.201808-3 20101206201808   pom 0.0.1-20101206.201808-3 20101206201808   
  • Ejecutar dependencias de actualización (en la máquina B) en m2eclipse (m3 final incrustado) -> repository local tiene snapshot.jar + snapshot-timestamp.jar 🙁

  • ejecutar el objective del paquete con maven externo 2.2.1 -> repository local tiene snapshot.jar + snapshot-timestamp.jar 🙁

Entonces, para recapitular: el objective de “implementación” en maven3 funciona mejor que en 2.2.1, el repository 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 repositorys -> el repository local todavía tiene instantáneas con marca de tiempo 🙁

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

Para eliminar estos de Nexus, puede crear fácilmente un trabajo automatizado para purgar el repository 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 repository local en una máquina de desarrollador llegan desde el objective 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).

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

  org.codehaus.mojo build-helper-maven-plugin 1.7   remove-old-artifacts package  remove-project-artifact   true     

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 comstackció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 progtwig pequeño. El progtwig final parece estar funcionando bastante bien en nuestro entorno. Así que decidí compartirlo con otras personas que puedan necesitar esa herramienta. Las fonts se pueden extraer de github: https://github.com/nadestin/tools/tree/master/MavenCacheCleanup

En cuanto a la parte del repository 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 fonts 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 repository (o hasta que lo expire a mano). Con suerte, entonces no necesitará tener un montón de SNAPSHOTs en su repository local.

Eso es a menos que esté hablando de un servidor de comstackció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 comstackción, hemos eludido esa bala haciendo que cada comstackción use su propio espacio de trabajo y repository local (aunque en Maven 2.2.1, ciertas cosas como Los POM parecen salir siempre del ~ / .m2 / repository). Las SNAPSHOT adicionales solo se quedan en una única comstackció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 repository. Esta opción (en Hudson) se llama “Usar repository 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 repository 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 repository de Maven. La ventaja de esto es que puede ahorrar espacio en el disco, pero la desventaja de esto es que a veces esas comstackciones pueden interferir entre sí. Por ejemplo, puede que las comstackciones tengan un éxito incorrecto, simplemente porque tiene todas las dependencias en su repository local, a pesar de que ninguno de los repositorys 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 repository local.

Cuando esta opción está marcada, Hudson le indicará a Maven que use $ WORKSPACE / .repository como el repository local de Maven. Esto significa que cada trabajo obtendrá su propio repository 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.

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 repository establecida por maven en la propiedad settings.localRepository y luego enlazada a través de la configuración en el repository variables:

   org.codehaus.gmavenplus gmavenplus-plugin 1.3   install  execute       repository ${settings.localRepository}         org.codehaus.groovy groovy-all 2.3.7 runtime    

Agregue el siguiente parámetro en su archivo POM

POM

  true  

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

Ejemplo de POM

   org.apache.maven.plugins maven-dependency-plugin 2.10   copy package  copy     junit junit 3.8.1 jar false ${project.build.directory}/alternateLocation optional-new-name.jar   **true** ${project.build.directory}/wars false true       

Configurar en Jenkins:

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