Maven não consegue encontrar artefato local

Ocasionalmente, o maven reclama que uma dependência específica, que é construída e empacotada localmente, não pode ser encontrada no repositório local durante a construção de outro projeto que a tenha como dependência. Recebemos um erro como:

Falha ao executar a meta no projeto X: Não foi possível resolver dependências para o projeto X: Falha ao encontrar Y em [repositório archiva] foi armazenado em cache no repositório local, a resolução não será tentada novamente até que o intervalo de atualização de interno tenha decorrido ou as atualizações sejam forçadas - >

Onde X é o projeto sendo construído e Y é o artefato supostamente ausente. Se você olhar no repositório local, o artefato está lá. Este artefato nunca é instalado em nosso repositório archiva, então o problema é puramente baseado no repositório local.

Tentamos vários perfis em settings.xml e, claro, "mvn -U". Não fazem bem, nem deveriam, porque este artefato nunca vai além do repositório local.

As únicas duas coisas que parecem funcionar são esperar muito tempo até que o maven se torne mais inteligente ou deletar completamente o repositório local. Presumivelmente, a opção de espera está relacionada ao intervalo de atualização mencionado.

Tivemos esse problema com o maven 3.0.2 e 3.0.3. Estamos usando o Archiva 1.0.3 (mas, novamente, isso não deve ser um fator). Qualquer ajuda seria muito apreciada.

O repositório Maven local rastreia de onde os artefatos vieram originalmente usando um arquivo denominado "_maven.repositories" no diretório de artefatos. Depois de removê-lo, a construção funcionou. Essa resposta resolveu o problema para mim.

Como as opções aqui não funcionaram para mim, estou compartilhando como resolvi isso:

Meu projeto tem um projeto pai (com seu próprio pom.xml) que tem muitos módulos filhos, um dos quais (A) tem dependência de outro filho (B). Quando tentei mvn packageem A, não funcionou porque B não pôde ser resolvido.

Executar mvn install no diretório pai funcionou. Depois disso, eu poderia fazer mvn packagedentro de A e só então poderia encontrar B.

Mesmo no modo offline, o maven verificará os repositórios remotos se houver um marcador _remote.repositories para a dependência. Se precisar operar no modo off-line, pode ser necessário excluir esses arquivos.

O comando shell simples abaixo exclui esses arquivos marcadores. É seguro fazer isso se você usar o modo off-line para a máquina. Eu NÃO faria isso em uma máquina que precisa puxar arquivos da web.

Usei essa estratégia em um servidor de compilação que está desconectado da web. Temos que transferir o repositório para ele, deletar os arquivos do marcador e então executar no modo offline.

No Linux / Unix, você pode excluir os arquivos marcadores do repositório remoto desta forma:

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

Quando isso aconteceu comigo, foi porque eu copiei cegamente meu settings.xml de um modelo e ele ainda tinha o <localRepository/>elemento em branco . Isso significa que não há repositório local usado ao resolver dependências (embora seus artefatos instalados ainda sejam colocados no local padrão). Quando o substituí por <localRepository>${user.home}\.m2\repository</localRepository>ele começou a funcionar.

Para * nix, isso seria <localRepository>${user.home}/.m2/repository</localRepository>, suponho.

Maven lembra quando não encontrou algo. A chave é "a resolução não será tentada novamente até que o intervalo de atualização de interno tenha decorrido ou as atualizações sejam forçadas ->"

A solução rápida é excluir o subdiretório "repositório" local do artefato com problema - assumindo que você tenha corrigido o problema com ele. :)

mvn -U irá forçar a atualização do repositório remoto - novamente, assumindo que você já tenha populado o remoto com o referido artefato.

Pegue tudo. Quando as soluções mencionadas aqui não funcionam (aconteceu no meu caso), simplesmente exclua todo o conteúdo da pasta / diretório '.m2' e faça mvn clean install.

Se você <repositories/>definiu em seu pom.xml, aparentemente, seu repositório local será ignorado.

Até eu enfrentei esse problema e resolvi de 2 maneiras:

1) Em seu IDE, selecione o projeto e limpe todos os projetos e, em seguida, instale todas as dependências do maven clicando com o botão direito do mouse no projeto -> vá para maven e Atualizar as dependências do projeto selecione todos os projetos de uma vez para instalar os mesmos. Uma vez feito isso, execute o projeto específico

2) Outra coisa que você pode fazer é verificar no pom.xml as dependências para as quais você está obtendo o erro e "mvn clean install" primeiro para esses projetos dependentes e instalar as dependências do maven do projeto atual no qual você está enfrentando problemas. Com isso, as dependências do projeto local serão construídas e os jars serão criados.

Eu corro para o problema semelhante quando meu novo projeto depende do oracle jdbc jar (que instalei em meu repositório local e funciona bem para outros projetos). Tentei a opção -U, excluindo o arquivo .lastupdate ou todo o diretório e baixando novamente, mas não funcionou. finalmente, apaguei o diretório e instalei-o localmente novamente, ele funciona.

Um dos erros que encontrei no Maven é quando coloco meu arquivo settings.xml no diretório errado. Ele deve estar na pasta .m2 no diretório inicial do usuário. Certifique-se de que está no lugar certo (junto com settings-security.xml se você estiver usando).

Eu tinha DependencyResolutionExceptionno Ubuntu Linux quando instalei artefatos locais por meio de um script de shell. A solução foi deletar os artefatos locais e instalá-los novamente "manualmente" - chamando mvn install:install-filevia terminal.

Isso aconteceu porque eu tinha em httpvez httpsdisso:

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

verifique se o seu artefato Y tem a embalagem definida como "jar". Se você o definiu como "guerra" por erro ou copiar e colar, ele mostrará este estranho "foi armazenado em cache no repositório local, a resolução não será tentada novamente até que o intervalo de atualização de interno tenha decorrido ou as atualizações sejam forçadas". Eu esperaria algo como "artefato Y é guerra, é esperado o tipo jar".

Eu tive o mesmo erro por uma causa diferente: criei um POM inicial contendo nossas dependências de "boas práticas" e o construí e instalei localmente para testá-lo. Eu poderia "ver" no repositório, mas um projeto que o utilizou obteve o erro acima. O que eu fiz foi definir o POM inicial para pom, então não havia JAR. Maven estava bastante correto ao dizer que não estava no Nexus - mas eu não esperava que estivesse, então o erro foi, hummm, inútil. Alterar o POM inicial para a embalagem normal e reinstalar corrigiu o problema.