Maven не может найти локальный артефакт

108

Иногда maven жалуется, что конкретная зависимость, которая создается и упаковывается локально, не может быть найдена в локальном репозитории при создании другого проекта, в котором она используется в качестве зависимости. Получаем такую ​​ошибку:

Не удалось выполнить цель в проекте X: не удалось разрешить зависимости для проекта X: не удалось найти Y в [архивном репозитории], было кэшировано в локальном репозитории, разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно - >

Где X - строящийся проект, а Y - предположительно отсутствующий артефакт. Если вы посмотрите в локальном репозитории, артефакт там. Этот артефакт никогда не устанавливается в наш архивный репозиторий, поэтому проблема связана исключительно с локальным репозиторием.

Мы пробовали различные профили в settings.xml и, конечно же, "mvn -U". Ничего хорошего и не должно, потому что этот артефакт никогда не выходит за пределы локального репозитория.

Единственные две вещи, которые кажутся работоспособными, - это подождать очень долгое время, пока maven не улучшится, или полностью удалить локальный репозиторий. Предположительно вариант ожидания связан с вышеупомянутым интервалом обновления.

Мы столкнулись с этой проблемой с maven 3.0.2 и 3.0.3. Мы используем Archiva 1.0.3 (но опять же это не должно быть фактором). Любая помощь будет принята с благодарностью.

user1686620
источник
1
Регистрирует ли Maven что-нибудь во время или непосредственно перед "ожиданием"? Т.е. он пытается подключиться к недоступному репозиторию? Кроме того, являются ли проблемные артефакты "-SNAPSHOT"?
noahlz
Maven не регистрирует ничего, кроме упомянутой выше ошибки. И да, это зависимость от снимка.
user1686620
1
Вы установили пакет сборки до того, как попытаетесь собрать второй проект?
khmarbaise
3
Мне нравится, что сообщение об ошибке является продолжением, а не грамматически правильным предложением. Таким образом, мы не знаем наверняка, не может ли он найти Y, или Y был кэширован локально, или и то, и другое. Во всяком случае, у меня похожая проблема. Мне удалось решить эту проблему с помощью опции -U, потому что мои зависимости находятся во внутреннем репозитории моей компании. Почему необходимые артефакты не развернуты во внутреннем репозитории вашей компании?
jyoungdev

Ответы:

81

Локальный репозиторий Maven отслеживает происхождение артефактов с помощью файла с именем «_maven.repositories» в каталоге артефактов. После его удаления сборка заработала. Этот ответ решил проблему для меня.

Джансон
источник
26
Для меня это был файл с именем "_remote.repositories". Я удалил и все заработало! Спасибо за хитрости!
perbellinio
2
Спасибо, файл с именем _remote.repositories также присутствовал. это случилось со мной, когда наш нексус перестал подключаться к сети, поэтому он не может получить зависимости
cabaji99
1
Предоставленное решение действительно работает. Однако меня интересует, почему вообще возникает эта проблема. Может ли кто-нибудь дать мне быстрое объяснение? Должен ли я делать что-то по-другому?
Janothan
Если вы хотите обойти эту проверку происхождения один раз (без удаления метафайлов), попробуйте перейти aether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameк процессу разрешения зависимостей; Самый простой способ - добавить системное свойство -D к команде вызова.
Джанака Бандара
@Janothan IMO ссылка в ответе дает довольно хорошее объяснение :)
Джанака Бандара
40

Поскольку варианты здесь не работали для меня, я рассказываю, как я это решил:

В моем проекте есть родительский проект (с собственным pom.xml), в котором много дочерних модулей, один из которых (A) зависит от другого дочернего (B). Когда я попробовал mvn packageв A, это не сработало, потому что B не может быть решен.

Выполнение mvn install в родительском каталоге выполнило свою работу. После этого я мог делать mvn packageвнутри A и только тогда он мог найти B.

Флориан Пфистерер
источник
3
СПАСИБО! это сводило меня с ума. mvn clean package jboss-as: deploy работал, когда я выполнял их в одной строке, но не когда я выполнял их отдельно.
PMorganCA
19

Даже в автономном режиме maven будет проверять удаленные репозитории на наличие маркера _remote.repositories для зависимости. Если вам нужно работать в автономном режиме, вам может потребоваться удалить эти файлы.

Приведенная ниже простая команда оболочки удаляет эти файлы маркеров. Это безопасно, если вы используете для аппарата только автономный режим. Я бы НЕ делал это на машине, которой нужно скачивать файлы из Интернета.

Я использовал эту стратегию на сервере сборки, который отключен от Интернета. Нам нужно перенести в него репозиторий, удалить файлы маркеров и затем запустить в автономном режиме.

В Linux / Unix вы можете удалить файлы маркеров удаленного репозитория следующим образом:

cd ~/.m2
find . -name "_remote.repositories" -type f -delete
Джон
источник
1
Это решение сработало для меня из-за зависимости, которую я скопировал с другого компьютера, которая недоступна в центральном репозитории. Однако в команде отсутствует несколько символов. Вот полная команда: найти. -name "_remote.repositories" -type -f -delete
Ханс Дерагон
2
Или, вместо удаления, вы сможете «ввести в заблуждение» Maven, чтобы он не смотрел _remote.repositoriesфайл, передавая -Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameего процессу. (Не пробовал настоящую сборку Maven, но работает при программном вызове Maven; поэтому первая также должна работать)
Джанака Бандара
1
Я обнаружил и удалил определенные зависимости (jar-файлы), не найденные Maven, так как они были перечислены и управляемы до (<10). Это произошло из-за неправильной конфигурации, указывающей на удаленный Nexus, который в настоящее время недоступен (как я понял ..). Таким образом, нет реальной необходимости очищать все репо для удаления. В любом случае это решение спасло положение. Это работает для меня.
Diego1974
9

Когда это случилось со мной, это произошло потому, что я слепо скопировал свой файл settings.xml из шаблона, но в нем все еще оставался пустой <localRepository/>элемент. Это означает, что при разрешении зависимостей не используется локальный репозиторий (хотя установленные вами артефакты по-прежнему помещаются в местоположение по умолчанию). Когда я заменил это, <localRepository>${user.home}\.m2\repository</localRepository>он начал работать.

Для * nix это будет <localRepository>${user.home}/.m2/repository</localRepository>Полагаю, .

Пол Хикс
источник
6
По умолчанию используется $ {user.home} \. m2 \ repository, поэтому удаление пустого тега должно работать одинаково.
Луис Муньос,
9

Maven помнит, когда что-то не нашла. Ключ заключается в том, что "разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно ->"

Быстрое решение - удалить локальный подкаталог "репозитория" для проблемного артефакта - при условии, что вы устранили проблему с ним. :)

mvn -U принудительно обновит удаленный репозиторий - опять же, если вы заполнили удаленный репозиторий указанным артефактом.

Андре
источник
2

Поймай все. Когда упомянутые здесь решения не работают (это случилось в моем случае), просто удалите все содержимое из папки / каталога '.m2' и сделайте это mvn clean install.

люпхиазоем
источник
2

Если вы <repositories/>определили в своем pom.xml, очевидно, ваш локальный репозиторий игнорируется.

Ярослав Заруба
источник
1

Даже я столкнулся с этой проблемой и решил ее двумя способами:

1) В вашей среде IDE выберите проект и очистите все проекты, затем установите все зависимости maven, щелкнув правой кнопкой мыши проект → перейдите к maven и обновите зависимости проекта, выберите все проекты сразу, чтобы установить то же самое. Как только это будет сделано, запустите конкретный проект.

2) Иное. Что вы можете сделать, так это проверить в pom.xml зависимости, для которых вы получаете ошибку, и сначала выполнить mvn clean install для этих зависимых проектов, а также установить maven-зависимости текущего проекта, в котором вы столкнулись с проблемой. Таким образом будут построены зависимости локального проекта и созданы jar-файлы.

Неха Тавар
источник
0

Я сталкиваюсь с аналогичной проблемой, когда мой новый проект зависит от jdbc jar oracle (который я установил в моем локальном репозитории и хорошо работает для других проектов). Я попробовал опцию -U, удалив файл .lastupdate или весь каталог и снова загрузил, но это не сработало. наконец, я удалил каталог и снова установил его локально, все работает.

yuxh
источник
0

Одна из ошибок, которые я обнаружил в Maven, - это когда я помещаю свой файл settings.xml не в тот каталог. Он должен находиться в папке .m2 в домашнем каталоге пользователя. Убедитесь, что он находится в нужном месте (вместе с settings-security.xml, если вы его используете).

Ашик Уззаман
источник
0

У меня было DependencyResolutionExceptionв Ubuntu Linux, когда я устанавливал локальные артефакты через сценарий оболочки. Решением было удалить локальные артефакты и снова установить их «вручную» - mvn install:install-fileчерез терминал.

naXa
источник
0

Это произошло потому, что httpвместо этого у меня было https:

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>
синтаксический анализатор
источник
0

проверьте, установлена ​​ли для вашего артефакта Y упаковка "jar". Если вы определили это как «войну» из-за ошибки или копирования и вставки, будет показано, что это странное «было кэшировано в локальном репозитории, разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно». Я ожидал чего-то вроде «артефакт Y - война, ожидается баночка».

Патрик Хрмо
источник
-1

У меня была такая же ошибка по другой причине: я создал стартовый POM, содержащий наши «хорошие практики» зависимости, и собрал и установил его локально, чтобы протестировать. Я мог «видеть» это в репо, но проект, который его использовал, получил указанную выше ошибку. Я установил стартовый POM на pom, поэтому JAR не было. Maven был совершенно прав, что этого не было в Nexus, но я не ожидал, что это будет, поэтому ошибка была, ммм, бесполезной. Замена стартового ПОМ на обычную упаковку и переустановка устранили проблему.

ЭдмундСС
источник
Этот ответ, вероятно, был бы лучше в качестве комментария, поскольку это не прямой ответ на вопрос.
00prometheus