Maven no encuentra el artefacto local

Question

Ocasionalmente, maven se queja de que una dependencia particular, que está construida y empaquetada localmente, no se puede encontrar en el repositorio local mientras se construye otro proyecto que la tiene como dependencia. Obtenemos un error como:

Error al ejecutar el objetivo en el proyecto X: No se pudo resolver las dependencias para el proyecto X: Si no se encuentra Y en [repositorio archiva] fue almacenado en caché en el repositorio local, no se volverá a intentar la resolución hasta el intervalo de actualización interno ha transcurrido o las actualizaciones son forzadas ->

Donde X es el proyecto que se está construyendo, y Y es el artefacto supuestamente perdido. Si miras en el repositorio local, el artefacto está allí. Este artefacto nunca se instala en nuestro repositorio archiva, por lo que el problema se basa exclusivamente en el repositorio local.

Hemos intentado varios perfiles en settings.xml, y por supuesto "mvn -U". Tampoco hacen ningún bien, ni deberían hacerlo, porque este artefacto nunca va más allá del repositorio local.

Las únicas dos cosas que parecen funcionar son esperar mucho tiempo hasta que maven se active o eliminar por completo el repositorio local. Presumiblemente, la opción de espera está relacionada con el intervalo de actualización antes mencionado.

Hemos tenido este problema con maven 3.0.2 y 3.0.3. Estamos usando Archiva 1.0.3 (pero nuevamente esto no debería ser un factor). Cualquier ayuda sería muy apreciada.

Answer 1

Cuando esto me sucedió a mí, fue porque había copiado a ciegas mi settings.xml de una plantilla y todavía tenía el elemento <localRepository/> en blanco. Esto significa que no hay un repositorio local utilizado para resolver dependencias (aunque los artefactos instalados todavía se ponen en la ubicación predeterminada). Cuando lo reemplacé con <localRepository>${user.home}\.m2\repository</localRepository>, comenzó a funcionar.

Para * nix, eso sería <localRepository>${user.home}/.m2/repository</localRepository>, supongo.

Answer 2

El repositorio local de Maven rastrea de dónde provienen originalmente los artefactos utilizando un archivo llamado "_maven.repositories" en el directorio de artefactos. Después de eliminarlo, la compilación funcionó. This answer me arregló el problema.

Answer 3

Maven recuerda cuando no encontró algo. La clave es "la resolución no se volverá a intentar hasta que haya transcurrido el intervalo de actualización interna o se fuercen las actualizaciones ->"

La solución rápida es eliminar su subdirectorio "repositorio" local para el artefacto problemático, suponiendo que haya solucionado el problema problema con eso. :)

mvn -U forzará la actualización desde el repositorio remoto - nuevamente, asumiendo que ahora ha poblado el control remoto con dicho artefacto.

Answer 4

Corro el problema similar cuando mi nuevo proyecto depende de Oracle jdbc jar (que he instalado en mi repositorio local y funciona bien para otros proyectos). Intenté la opción -U, eliminando el archivo .lastupdate o todo el directorio y la descarga nuevamente, pero no funcionó. finalmente, eliminé el directorio y lo instalé localmente de nuevo, funciona.

Answer 5

Uno de los errores que encontré en Maven es cuando coloco mi archivo settings.xml en el directorio incorrecto. Tiene que estar en la carpeta .m2 debajo de su directorio de inicio de usuario. Verifique que esté en el lugar correcto (junto con settings-security.xml si está usando eso).

Answer 6

Tuve DependencyResolutionException en Ubuntu Linux cuando instalé artefactos locales a través de un script de shell. La solución fue eliminar los artefactos locales e instalarlos de nuevo "manualmente" - llamando al mvn install:install-file a través del terminal.

Answer 7

Por favor, intente con este comando.

mvn validar

Answer 8

Como las opciones aquí no funcionó para mí, que estoy compartiendo cómo lo resolví:

que mi proyecto, hay un proyecto principal (con su propio pom.xml) que tiene muchos módulos hijos, uno de los cuales (A) tiene una dependencia con otro hijo (B). Cuando probé mvn package en A, no funcionó porque B no se pudo resolver.

Ejecutando mvn installen el directorio principal hizo el trabajo. Después de eso, podría hacer mvn package dentro de A y solo entonces podría encontrar B.

Answer 9

Incluso en modo fuera de línea, maven comprobará los repositorios remotos si hay un marcador _remote.repositories para la dependencia. Si necesita operar en modo fuera de línea, es posible que deba eliminar estos archivos.

A continuación tengo un comando de shell simple para eliminar estos archivos de marcador. Esto es seguro de hacer si solo usa el modo fuera de línea para la máquina. NO HAGO esto en una máquina que necesita extraer archivos de la web.

He utilizado esta estrategia en un servidor de compilación que está desconectado de la web. Tenemos que transferir el repositorio a él, eliminar los archivos de marcador y luego ejecutar en modo fuera de línea.

En Linux/Unix puede eliminar los archivos remotos marcadores repositorio de esta manera:

cd ~/.m2 
find -name "_remote.repositories" type -f -delete