Maven no encuentra el artefacto local

107

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

No se pudo ejecutar el objetivo en el proyecto X: No se pudieron resolver las dependencias para el proyecto X: No se pudo encontrar Y en el [repositorio de archiva] 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 interno o las actualizaciones sean forzadas - >

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

Hemos probado varios perfiles en settings.xml y, por supuesto, "mvn -U". No sirven de nada, 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 mejore o eliminar por completo el repositorio local. Es de suponer que la opción de espera está relacionada con el intervalo de actualización mencionado anteriormente.

Hemos experimentado 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á muy apreciada.

user1686620
fuente
1
¿Maven registra algo mientras o justo antes de la "espera"? Es decir, ¿está intentando conectarse a un repositorio inalcanzable? Además, ¿los artefactos problemáticos son "-SNAPSHOT"?
noahlz
Maven no registra nada más que el error que mencioné anteriormente. Y sí, esta es una dependencia de instantánea.
user1686620
1
¿Ha instalado el paquete de compilación antes de intentar compilar el segundo proyecto?
Khmarbaise
3
Me gusta cómo el mensaje de error es una frase corrida, no una oración gramaticalmente correcta. De esta manera, no sabemos con certeza si no puede encontrar Y o si Y se almacenó en caché localmente, o ambos. De todos modos, tengo un problema similar. Pude resolverlo con la opción -U porque mis dependencias están en el repositorio interno de mi empresa. ¿Por qué no se implementan los artefactos que necesita en el repositorio interno de su empresa?
jyoungdev

Respuestas:

77

El repositorio local de Maven rastrea el origen de los artefactos mediante un archivo llamado "_maven.repositories" en el directorio de artefactos. Después de quitarlo, la construcción funcionó. Esta respuesta me solucionó el problema.

jhanson
fuente
26
Para mí, era un archivo llamado "_remote.repositories". ¡Lo quité y funcionó! ¡Gracias por los trucos!
perbellinio
2
Gracias al archivo llamado _remote.repositories también estaba presente. me sucedió cuando nuestro nexo dejó de tener conexión de red, por lo que no puede obtener las dependencias
cabaji99
1
La solución proporcionada funciona. Sin embargo, estoy interesado en saber por qué ocurre este problema. ¿Alguien podría darme una explicación rápida? ¿Tengo que hacer algo diferente?
Janothan
Si desea omitir esta verificación de origen una vez (sin eliminar los metarchivos), intente pasar aether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameal proceso de resolución de dependencias; La forma más sencilla es agregar una propiedad del sistema -D al comando de invocación.
Janaka Bandara
@Janothan En mi opinión, el enlace en la respuesta proporciona una explicación bastante buena :)
Janaka Bandara
40

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

Mi proyecto tiene un proyecto principal (con su propio pom.xml) que tiene muchos módulos secundarios, uno de los cuales (A) depende de otro secundario (B). Cuando probé mvn packageen A, no funcionó porque B no se pudo resolver.

Ejecutar mvn install en el directorio principal hizo el trabajo. Después de eso, pude hacer mvn packagedentro de A y solo entonces podría encontrar B.

Florian Pfisterer
fuente
3
¡GRACIAS! Esto me estaba volviendo loco. mvn clean package jboss-as: deploy estaba funcionando cuando ejecuté en una sola línea, pero no cuando lo hice por separado.
PMorganCA
18

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.

El siguiente comando de shell simple elimina estos archivos de marcadores. Esto es seguro si solo usa el modo fuera de línea para la máquina. NO haría esto en una máquina que necesita extraer archivos de la web.

He usado esta estrategia en un servidor de compilación que está desconectado de la web. Tenemos que transferirle el repositorio, eliminar los archivos de marcadores y luego ejecutarlo en modo fuera de línea.

En Linux / Unix, puede eliminar los archivos de marcadores del repositorio remoto de esta manera:

cd ~/.m2
find . -name "_remote.repositories" -type f -delete
Jon
fuente
1
Esta solución funcionó para mí, para una dependencia que copié desde otra computadora que no está disponible en un repositorio central. Sin embargo, el comando pierde algunos caracteres. Aquí está el comando completo: buscar. -nombre "_remote.repositories" -type -f -delete
Hans Deragon
2
O, en lugar de eliminarlo, debería poder "desviar" a Maven para que no mire el _remote.repositoriesarchivo pasando -Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameal proceso. (No probé una compilación real de Maven, pero funciona cuando se invoca a Maven programáticamente; por lo que la primera también debería funcionar)
Janaka Bandara
1
Hice esto para encontrar y eliminar dependencias específicas (jar) que Maven no encontró, ya que estaban en la lista y eran manejables para (<10). Esto se debió a un error de configuración que apuntaba a un Nexus remoto que no estaba disponible actualmente (según entendí ...). Por lo tanto, no es necesario barrer todos los repositorios para su eliminación. De todos modos, esta solución salvó el día. Funciona para mi.
Diego 1974
9

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

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

Paul Hicks
fuente
6
$ {user.home} \. m2 \ repository es el predeterminado, por lo que eliminar la etiqueta vacía debería funcionar igual.
Luis Muñoz
9

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

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

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

Andre
fuente
2

Atrapa todos. Cuando las soluciones mencionadas aquí no funcionan (sucedió en mi caso), simplemente elimine todo el contenido de la carpeta / directorio '.m2' y hágalo mvn clean install.

lupquiazoema
fuente
2

Si ha <repositories/>definido en su pom.xml, aparentemente se ignora su repositorio local.

Jaroslav Záruba
fuente
1

Incluso me enfrenté a este problema y lo resolví de 2 formas:

1) En su IDE, seleccione el proyecto y limpie todos los proyectos, luego instale todas las dependencias de maven haciendo clic derecho en el proyecto -> vaya a maven y actualice las dependencias del proyecto, seleccione todos los proyectos a la vez para instalar el mismo. Una vez hecho esto, ejecute el proyecto en particular

2) más lo que se puede hacer es comprobar en el pom.xml de las dependencias para el que está recibiendo el error y "MVN instalación limpia" los dependientes primer proyecto y las dependencias instalar Maven del proyecto actual en la que se enfrenta tema. Con esto se construirán las dependencias del proyecto local y se crearán los frascos.

Neha Tawar
fuente
0

Me encuentro con un problema similar cuando mi nuevo proyecto depende de oracle jdbc jar (que he instalado en mi repositorio local y funciona bien para otros proyectos). Probé la opción -U, eliminando el archivo .lastupdate o el directorio completo y lo descargué nuevamente, pero no funcionó. finalmente, eliminé el directorio y lo instalé localmente nuevamente, funciona.

yuxh
fuente
0

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 para asegurarse de que esté en el lugar correcto (junto con settings-security.xml si lo está usando).

Ashik Uzzaman
fuente
0

Lo tenía DependencyResolutionExceptionen 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 a mvn install:install-filetravés de la terminal.

naXa
fuente
0

Esto sucedió porque tenía en httplugar de httpsesto:

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>
parsecer
fuente
0

compruebe si su artefacto Y tiene empaquetado configurado en "jar". Si lo ha definido como "guerra" por error o copiar y pegar, mostrará este extraño "se almacenó en caché en el repositorio local, no se volverá a intentar la resolución hasta que haya transcurrido el intervalo de actualización interno o las actualizaciones sean forzadas". Yo esperaría algo como "el artefacto Y es guerra, se espera el tipo jar".

Patrik Hrmo
fuente
-1

Tuve el mismo error por una causa diferente: había creado un POM de inicio que contenía nuestras dependencias de "buenas prácticas", y lo había construido e instalado localmente para probarlo. Pude "verlo" en el repositorio, pero un proyecto que lo usó obtuvo el error anterior. Lo que hice fue configurar el POM inicial en pom, por lo que no había JAR. Maven tenía bastante razón en que no estaba en Nexus, pero no esperaba que lo estuviera, por lo que el error fue, ummm, inútil. Cambiar el POM inicial a un embalaje normal y reinstalar solucionó el problema.

EdmundSS
fuente
Esta respuesta probablemente hubiera sido mejor como comentario, ya que no es una respuesta directa a la pregunta.
00prometheus