Maven no encuentra el artefacto local

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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).

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.

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

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

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".

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.