Cuando maven dice "la resolución no se volverá a intentar hasta que haya transcurrido el intervalo de actualización de MyRepo", ¿dónde se especifica ese intervalo?


587

Con Maven, ocasionalmente encuentro un artefacto que proviene de un repositorio de terceros que aún no he construido o incluido en mi repositorio.

Recibiré un mensaje de error del cliente de Maven diciendo que no se puede encontrar un artefacto

Si no se encuentra org.jfrog.maven.annomojo: maven-plugin-anno: jar: 1.4.0 http://myrepo:80/artifactory/repose almacenó en caché en el repositorio local, la resolución no se volverá a intentar hasta que haya transcurrido el intervalo de actualización de MyRepo o se hayan forzado las actualizaciones -> [ Ayuda 1]

Ahora, yo entiendo lo que esto significa, y simplemente puede volver a ejecutar mi mando con -U, y cosas por lo general los finos trabajos de ahí en adelante .

Sin embargo, considero que este mensaje de error es extremadamente poco intuitivo y estoy tratando de evitar algunos dolores de cabeza a mis compañeros de trabajo.

Estoy tratando de averiguar si hay algún lugar donde pueda modificar esta update intervalconfiguración.

  1. ¿Es lo update intervalque se menciona en este mensaje de error una configuración del lado del cliente o del servidor?
  2. Si es del lado del cliente, ¿cómo lo configuro?
  3. Si es del lado del servidor, ¿alguien sabe cómo / si Nexus / Artifactory expone esta configuración?

11
Recibí el mismo mensaje de error después de agregar 1 dependencia más a mi pom.xml. Para mí esto es claramente un ERROR. ¡No entiendo por qué sucede esto! Si agrego dependencias a mi proyecto y ejecuto mvn compile, debería descargar los archivos jar. ¡Este comportamiento es totalmente absurdo!
Robert Reiz


Hace poco experimenté esto y después de todas las respuestas que he leído, otro paso adicional es volver a importar el proyecto en Eclipse (en mi caso). Era demasiado extraño que Eclipse me siguiera molestando con un complemento que no está en mi pom.xml.
Incognito

¡Una pregunta importante para mí! ¡Gracias amigo!
Sr. Noddy

Para mí, resultó que un repositorio particular estaba vinculado a GitHub y la url se desconectó (obteniendo 404). Actualicé el repositorio a nuestro servidor interno y funcionó.
cbmeeks

Respuestas:


286

Solía ​​resolver este problema eliminando el directorio correspondiente que no pudo descargar el artefacto en mi repositorio local. La próxima vez que ejecute el comando maven, la descarga del artefacto se activa nuevamente. Por lo tanto, diría que es una configuración del lado del cliente.

Lado del Nexus (lado del repositorio del servidor), este problema se resuelve configurando una tarea programada. Del lado del cliente, esto se hace usando -U, como ya señaló.


77
"Solía ​​resolver este problema eliminando el directorio correspondiente que no pudo descargar el artefacto en mi repositorio local". Esto funcionó para mí. Estoy usando Netbeans también.

16
Si Maven observa que el artefacto almacenado en caché no es válido, ¿por qué no puede resolverlo por sí solo?
Stefan

1
¿Qué significa "configurar una tarea programada" y "esto se hace usando -U"? ¿Puede por favor poner esto en términos objetivos de Eclipse UI?
user2568374

1
Supongo que te refieres a Eclipse IDE. La teoría es que necesita descargar la última SNAPSHOT. Para hacerlo, debe agregar el parámetro '-U' a su comando maven, por ejemplo, mvn clean compile -U. Ahora, puede ejecutar este comando maven ya sea a través de la línea de comando o a través de Eclipse marcando la casilla 'siempre actualizar instantánea'. No estoy seguro, uso intellij en estos días. La parte 'configurar una tarea programada' se refiere a una configuración particular que desea tener en su servidor Nexus. Esto último no tiene nada que ver con Eclipse como tal.
Christian Achilli

10
Esto no responde a la pregunta real de los OP.
8bitjunkie

116

puede eliminar el directorio de artefactos fallidos correspondiente en su repositorio local. Y también puedes usar simplemente -Uen el objetivo. Hará el trabajo. Esto funciona con maven 3. Por lo tanto, no es necesario degradar a maven 2.


2
¿Por qué jugar con la configuración del repositorio cuando puede ser tan simple?
Koraktor

99
Lea la pregunta detenidamente antes de responder. OP pregunta cómo establecer el intervalo de tiempo, no cómo forzar una actualización.
i3ensays

2
No es una respuesta a la pregunta, pero esto es lo que las personas necesitan cuando llegan a esta excepción. Porque cuando está trabajando en un desarrollo de lib local, lo mejor es eliminar dicha lib en lugar de permitir que el intervalo lo confunda.
mcvkr

Deberíamos agregar repositorios válidos ~/.m2/settings.xml/<repositories>para resolver este problema con las opciones -U
Kanagavelu Sugumar

64

Tuve un problema relacionado, pero la respuesta de Raghuram ayudó. (Todavía no tengo suficiente reputación para votar su respuesta). Estoy usando Maven incluido con NetBeans, y estaba obteniendo el mismo "... fue almacenado en caché en el repositorio local, la resolución no se volverá a intentar hasta que haya transcurrido el intervalo de actualización de nexus o se hayan forzado las actualizaciones -> [Ayuda 1]" error .

Para solucionar esto, agregué <updatePolicy>always</updatePolicy>a mi archivo de configuración (C: \ Archivos de programa \ NetBeans 7.0 \ java \ maven \ conf \ settings.xml)

<profile>
  <id>nexus</id>
  <!--Enable snapshots for the built in central repo to direct -->
  <!--all requests to nexus via the mirror -->
  <repositories>
    <repository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
      <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
    </repository>
  </repositories>
 <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
      <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
    </pluginRepository>
  </pluginRepositories>
</profile>

8
No ayudó en mi caso.
arcy

64

Lo que sucede básicamente es que, según la política de actualización predeterminada de Maven, Maven buscará los frascos del repositorio a diario, por lo que si durante el primer intento su Internet no funcionara, no intentaría recuperar este frasco nuevamente hasta que pasen 24 horas.

Resolución:

Cualquiera de uso

mvn -U clean install

donde -U forzará la actualización del repositorio

o usar

<profiles>
    <profile>
      ...
      <repositories>
        <repository>
          <id>myRepo</id>
          <name>My Repository</name>
          <releases>
            <enabled>false</enabled>
            <updatePolicy>always</updatePolicy>
            <checksumPolicy>warn</checksumPolicy>
          </releases>
         </repository>
      </repositories>
      ...
    </profile>
  </profiles>

en su settings.xml


39

De acuerdo con la referencia de configuración :

updatePolicy: este elemento especifica con qué frecuencia deberían intentarse las actualizaciones. Maven comparará la marca de tiempo del POM local (almacenada en el archivo de metadatos maven de un repositorio) con el control remoto. Las opciones son: siempre, diariamente (predeterminado), intervalo: X (donde X es un número entero en minutos) o nunca.

Ejemplo:

<profiles>
    <profile>
      ...
      <repositories>
        <repository>
          <id>myRepo</id>
          <name>My Repository</name>
          <releases>
            <enabled>false</enabled>
            <updatePolicy>always</updatePolicy>
            <checksumPolicy>warn</checksumPolicy>
          </releases>
         </repository>
      </repositories>
      ...
    </profile>
  </profiles>
  ...
</settings>

77
Gracias por la respuesta; sin embargo, he experimentado bastante con la configuración "updatePolicy", y parece que no tiene ningún efecto en el error "No encontrado" / "Falla en caché" / "no se volverá a intentar".
cprice404

23

Si bien puede resolver esto con una instalación limpia (anulando cualquier dependencia almacenada en caché) como @ Sanjeev-Gulgani sugiere con mvn -U clean install

También puede simplemente eliminar la dependencia en caché que está causando el problema con

mvn dependency:purge-local-repository -DmanualInclude="groupId:artifactId"

Ver mvn docs para más información.


9

Este error a veces puede ser engañoso. 2 cosas que es posible que desee verificar:

  1. ¿Existe un JAR real para la dependencia en el repositorio? Su mensaje de error contiene una URL de dónde está buscando, vaya allí y luego busque la carpeta que coincida con su dependencia. ¿Hay un frasco? Si no, necesita cambiar su dependencia. (por ejemplo, podría estar apuntando a una dependencia principal de nivel superior, cuando debería estar apuntando a un subproyecto)

  2. Si el jar existe en el repositorio remoto, simplemente elimine su copia local. Estará en su directorio de inicio (a menos que haya configurado de manera diferente) en .m2 / repositorio (ls -a para mostrar oculto si está en Linux).


44
Esto no es relevante para la pregunta de OP. La razón por la que se muestra el error no es el punto. OP quiere saber cómo establecer el intervalo de reintento.
8bitjunkie

1
Este puede ser un problema implícito detrás de la publicación de OP y resultó ser mi problema. Resultó que tenía un error tipográfico en mi <groupId> que al revisar la opción uno me llevó por el camino correcto.
James Oravec

1
La pregunta es cómo establecer el intervalo?
smilyface

7

Si está utilizando Eclipse, vaya a Windows -> Preferencias -> Maven y desactive la casilla de verificación "No actualizar automáticamente las dependencias de los repositorios remotos".

Esto funciona con Maven 3 también.


1
verificado para: eclipse: Juno Service Release 2. m2e: v 1.3.1
user77115

8
Esto no responde la pregunta de OP.
8bitjunkie

5

Debe eliminar todos los archivos "_maven.repositories" de su repositorio.


3
no ayuda, o al menos no en mi caso
arcy

1
Funcionó para mi. Sin embargo, no los
eliminé

5

Esto funciona después de eliminar la dependencia relacionada de su repositorio local de Maven

/user/.m2/repository/path

Esto funciona a las
mil maravillas

3

Si usa Nexus como repositorio proxy, tiene la configuración "No encontrado TTL de caché" con un valor predeterminado de 1440 minutos (o 24 horas). Reducir este valor puede ayudar (Repositorios> Configuración> Configuración de caducidad).

Ver documentación para más información.


2

Cómo conseguí este problema

Cuando cambié de Eclipse Juno a Luna, y revisé mis proyectos maven del repositorio de SVN, tuve los mismos problemas al crear las aplicaciones.

Lo que probé? Intenté limpiar el repositorio local y luego actualizar todas las versiones nuevamente usando la opción -U. Pero mi problema continuó.

Luego fui a Ventana -> Preferencias -> Maven -> Configuración de usuario -> e hice clic en el botón Reindex en Repositorio local y espere a que ocurra la reindex.

Eso es todo, el problema está resuelto.


44
Esto no responde la pregunta de OP.
8bitjunkie

2

Para finalmente responder la pregunta del título: Es (una configuración del lado del cliente) en (proyecto, perfil o configuración)

[plugin]?[r|R]epository/[releases|snapshots]/updatePolicy

... etiqueta.

Los valores posibles (actualmente, maven: 3.6.0, pero supongo que son compatibles con "versiones anteriores") son:

/**
 * Never update locally cached data.
 */
public static final String UPDATE_POLICY_NEVER = "never";
/**
 * Always update locally cached data.
 */
public static final String UPDATE_POLICY_ALWAYS = "always";
/**
 * Update locally cached data once a day.
 */
public static final String UPDATE_POLICY_DAILY = "daily";
/**
 * Update locally cached data **every X minutes** as given by "interval:X".
 */
public static final String UPDATE_POLICY_INTERVAL = "interval";

La evaluación actual (maven 3.6.0) de esta etiqueta se implementa de la siguiente manera:

public boolean isUpdatedRequired( RepositorySystemSession session, long lastModified, String policy )
{
    boolean checkForUpdates;
    if ( policy == null )
    {
        policy = "";
    }
    if ( RepositoryPolicy.UPDATE_POLICY_ALWAYS.equals( policy ) )
    {
        checkForUpdates = true;
    }
    else if ( RepositoryPolicy.UPDATE_POLICY_DAILY.equals( policy ) )
    {
        Calendar cal = Calendar.getInstance();
        cal.set( Calendar.HOUR_OF_DAY, 0 );
        cal.set( Calendar.MINUTE, 0 );
        cal.set( Calendar.SECOND, 0 );
        cal.set( Calendar.MILLISECOND, 0 );
        checkForUpdates = cal.getTimeInMillis() > lastModified;
    }
    else if ( policy.startsWith( RepositoryPolicy.UPDATE_POLICY_INTERVAL ) )
    {
        int minutes = getMinutes( policy );
        Calendar cal = Calendar.getInstance();
        cal.add( Calendar.MINUTE, -minutes );
        checkForUpdates = cal.getTimeInMillis() > lastModified;
    }
    else
    {
        // assume "never"
        checkForUpdates = false;
        if ( !RepositoryPolicy.UPDATE_POLICY_NEVER.equals( policy ) )
        {
            LOGGER.warn( "Unknown repository update policy '{}', assuming '{}'",
                    policy, RepositoryPolicy.UPDATE_POLICY_NEVER );
        }
    }
    return checkForUpdates;
}

..con:

private int getMinutes( String policy )
{
    int minutes;
    try
    {
        String s = policy.substring( RepositoryPolicy.UPDATE_POLICY_INTERVAL.length() + 1 );
        minutes = Integer.valueOf( s );
    }
    catch ( RuntimeException e )
    {
        minutes = 24 * 60;
        LOGGER.warn( "Non-parseable repository update policy '{}', assuming '{}:1440'",
                policy, RepositoryPolicy.UPDATE_POLICY_INTERVAL );
    }
    return minutes;
}

... donde lastModifiedestá la "marca de tiempo modificada" (archivo local) de un / cada artefacto subyacente.


En particular para el interval:xentorno:

  • los dos puntos :no son tan estrictos: cualquier personaje "no vacío" podría hacerlo ( =, , ...).
  • valores negativos x < 0 deberían ceder a "nunca".
  • interval:0 Asumiría un intervalo "minucioso" (0-59 segundos o más ...).
  • las excepciones de formato de número dan como resultado 24 * 60minutos (~ "diario").

..ver: DefaultUpdatePolicyAnalyzer , DefaultMetadataResolver # resolveMetadata () y RepositoryPolicy


1

Para los usuarios de Intellij , lo siguiente funcionó para mí:

Haga clic derecho en su paquete

Maven > Reimport 

y

Maven > Generate Sources and Update Folders

0

Algo relevante ... Me estaba poniendo

"[ERROR] Error al ejecutar el objetivo en el proyecto de prueba del proyecto: no se pudieron resolver las dependencias del proyecto myjarname: jar: 1.0-0: no se encontró myjarname-core: paquete: 1.0-0 en el http://repo1.maven.org/maven2caché local, la resolución no será reintentado hasta que haya transcurrido el intervalo de actualización de central o se hayan forzado las actualizaciones -> [Ayuda 1] "

Este error fue causado por el uso accidental en Maven 3lugar de Maven 2. Solo pensé que podría ahorrarle tiempo a alguien, porque mi búsqueda inicial en Google me llevó a esta página.


2
¿Qué pasa si tu proyecto te obliga a usar Maven 3? ¿Tienes alguna idea de lo que cambió entre las dos versiones?
Xr.

1
Esto es exactamente cuál era mi problema. No tengo idea de por qué Maven 3 es tan diferente de 2. Gracias por publicar esto y evitar que pierda más tiempo buscando una solución.
CatsAndCode

¿Cómo instalar maven2 en lugar de maven3?
trillones

Pregunta muy genérica ... ¿qué sistema operativo? Para Ubuntu, puede hacer "sudo apt-get install maven2" ... o para cualquier Linux / UNIX, simplemente puede descargar el archivo y compilarlo usted mismo, agregándolo a su ruta. Prueba: shameerarathnayaka.blogspot.com/2012/01/…
sdanzig

Esto funcionó para mí y de hecho me conecto a esto desde mi respuesta aquí .
shiri

0

Maven tiene configuraciones de UpdatePolicy para especificar la frecuencia para verificar las actualizaciones en el repositorio o para mantener el repositorio sincronizado con el control remoto.

  • El valor predeterminado para updatePolicy es diario.
  • Otros valores pueden ser siempre / nunca / XX (especificando el intervalo en minutos).

El siguiente ejemplo de código se puede agregar al archivo de configuración de usuario de maven para configurar updatePolicy.

<pluginRepositories>
    <pluginRepository>
        <id>Releases</id>
        <url>http://<host>:<port>/nexus/content/repositories/releases/</url>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>             
</pluginRepositories>

3
Esto no responde la pregunta de OP. OP tiene claro que entienden cuál es el problema y cómo actualizar su repositorio m2 local. OP pregunta dónde se encuentra el intervalo y cómo cambiarlo. No se menciona ningún IDE en absoluto. No has leído la pregunta.
8bitjunkie

@ 8bitjunkie Lo anterior responde muy directamente a la pregunta: If client-side, how do I configure it?. Esta respuesta no se trata de ninguna función IDE. Es mvn solo la configuración del repositorio. El updatePolicyes el intervalo por el cual el OP pregunta.
montrivo

Esta podría ser la respuesta aceptada @ cprice404.
montrivo


0

Tuve este problema y las descripciones completas propuestas en este me ayudaron a solucionarlo.

El segundo problema declarado fue mi problema. Utilicé un repositorio de terceros que acababa de agregar para la repositoryparte del archivo pom en mi proyecto. Agrego la misma información de repositorio pluginrepositorypara resolver este problema.


0

Tuve un error similar con un artefacto diferente.

<...> se almacenó en caché en el repositorio local, la resolución no se volverá a intentar hasta que haya transcurrido el intervalo de actualización de central o se hayan forzado las actualizaciones

Ninguna de las soluciones descritas anteriormente funcionó para mí. Finalmente resolví esto en IntelliJ IDEA por Archivo> Invalidar cachés / reiniciar ...> Invalidar y reiniciar .


0

En mi caso tuve múltiples proyectos

rootProject
 |-> contractProject (using Project Lombok)
 |-> domainProject (dependency on contractProject)

Cuando hice "mvn clean install" desde el directorio "domainProject", recibí dicho error.

Cuando hice "mvn clean install" desde el directorio "projectRoot", el problema desapareció.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.