Иногда maven жалуется, что конкретная зависимость, которая создается и упаковывается локально, не может быть найдена в локальном репозитории при создании другого проекта, в котором она используется в качестве зависимости. Получаем такую ошибку:
Не удалось выполнить цель в проекте X: не удалось разрешить зависимости для проекта X: не удалось найти Y в [архивном репозитории], было кэшировано в локальном репозитории, разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно - >
Где X - строящийся проект, а Y - предположительно отсутствующий артефакт. Если вы посмотрите в локальном репозитории, артефакт там. Этот артефакт никогда не устанавливается в наш архивный репозиторий, поэтому проблема связана исключительно с локальным репозиторием.
Мы пробовали различные профили в settings.xml и, конечно же, "mvn -U". Ничего хорошего и не должно, потому что этот артефакт никогда не выходит за пределы локального репозитория.
Единственные две вещи, которые кажутся работоспособными, - это подождать очень долгое время, пока maven не улучшится, или полностью удалить локальный репозиторий. Предположительно вариант ожидания связан с вышеупомянутым интервалом обновления.
Мы столкнулись с этой проблемой с maven 3.0.2 и 3.0.3. Мы используем Archiva 1.0.3 (но опять же это не должно быть фактором). Любая помощь будет принята с благодарностью.
источник
Ответы:
Локальный репозиторий Maven отслеживает происхождение артефактов с помощью файла с именем «_maven.repositories» в каталоге артефактов. После его удаления сборка заработала. Этот ответ решил проблему для меня.
источник
aether.enhancedLocalRepository.trackingFilename=some_dummy_file_name
к процессу разрешения зависимостей; Самый простой способ - добавить системное свойство -D к команде вызова.Поскольку варианты здесь не работали для меня, я рассказываю, как я это решил:
В моем проекте есть родительский проект (с собственным pom.xml), в котором много дочерних модулей, один из которых (A) зависит от другого дочернего (B). Когда я попробовал
mvn package
в A, это не сработало, потому что B не может быть решен.Выполнение
mvn install
в родительском каталоге выполнило свою работу. После этого я мог делатьmvn package
внутри A и только тогда он мог найти B.источник
Даже в автономном режиме maven будет проверять удаленные репозитории на наличие маркера _remote.repositories для зависимости. Если вам нужно работать в автономном режиме, вам может потребоваться удалить эти файлы.
Приведенная ниже простая команда оболочки удаляет эти файлы маркеров. Это безопасно, если вы используете для аппарата только автономный режим. Я бы НЕ делал это на машине, которой нужно скачивать файлы из Интернета.
Я использовал эту стратегию на сервере сборки, который отключен от Интернета. Нам нужно перенести в него репозиторий, удалить файлы маркеров и затем запустить в автономном режиме.
В Linux / Unix вы можете удалить файлы маркеров удаленного репозитория следующим образом:
источник
_remote.repositories
файл, передавая-Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_name
его процессу. (Не пробовал настоящую сборку Maven, но работает при программном вызове Maven; поэтому первая также должна работать)Когда это случилось со мной, это произошло потому, что я слепо скопировал свой файл settings.xml из шаблона, но в нем все еще оставался пустой
<localRepository/>
элемент. Это означает, что при разрешении зависимостей не используется локальный репозиторий (хотя установленные вами артефакты по-прежнему помещаются в местоположение по умолчанию). Когда я заменил это,<localRepository>${user.home}\.m2\repository</localRepository>
он начал работать.Для * nix это будет
<localRepository>${user.home}/.m2/repository</localRepository>
Полагаю, .источник
Maven помнит, когда что-то не нашла. Ключ заключается в том, что "разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно ->"
Быстрое решение - удалить локальный подкаталог "репозитория" для проблемного артефакта - при условии, что вы устранили проблему с ним. :)
mvn -U
принудительно обновит удаленный репозиторий - опять же, если вы заполнили удаленный репозиторий указанным артефактом.источник
Поймай все. Когда упомянутые здесь решения не работают (это случилось в моем случае), просто удалите все содержимое из папки / каталога '.m2' и сделайте это
mvn clean install
.источник
Если вы
<repositories/>
определили в своем pom.xml, очевидно, ваш локальный репозиторий игнорируется.источник
Даже я столкнулся с этой проблемой и решил ее двумя способами:
1) В вашей среде IDE выберите проект и очистите все проекты, затем установите все зависимости maven, щелкнув правой кнопкой мыши проект → перейдите к maven и обновите зависимости проекта, выберите все проекты сразу, чтобы установить то же самое. Как только это будет сделано, запустите конкретный проект.
2) Иное. Что вы можете сделать, так это проверить в pom.xml зависимости, для которых вы получаете ошибку, и сначала выполнить mvn clean install для этих зависимых проектов, а также установить maven-зависимости текущего проекта, в котором вы столкнулись с проблемой. Таким образом будут построены зависимости локального проекта и созданы jar-файлы.
источник
Я сталкиваюсь с аналогичной проблемой, когда мой новый проект зависит от jdbc jar oracle (который я установил в моем локальном репозитории и хорошо работает для других проектов). Я попробовал опцию -U, удалив файл .lastupdate или весь каталог и снова загрузил, но это не сработало. наконец, я удалил каталог и снова установил его локально, все работает.
источник
Одна из ошибок, которые я обнаружил в Maven, - это когда я помещаю свой файл settings.xml не в тот каталог. Он должен находиться в папке .m2 в домашнем каталоге пользователя. Убедитесь, что он находится в нужном месте (вместе с settings-security.xml, если вы его используете).
источник
У меня было
DependencyResolutionException
в Ubuntu Linux, когда я устанавливал локальные артефакты через сценарий оболочки. Решением было удалить локальные артефакты и снова установить их «вручную» -mvn install:install-file
через терминал.источник
Это произошло потому, что
http
вместо этого у меня былоhttps
:источник
проверьте, установлена ли для вашего артефакта Y упаковка "jar". Если вы определили это как «войну» из-за ошибки или копирования и вставки, будет показано, что это странное «было кэшировано в локальном репозитории, разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно». Я ожидал чего-то вроде «артефакт Y - война, ожидается баночка».
источник
У меня была такая же ошибка по другой причине: я создал стартовый POM, содержащий наши «хорошие практики» зависимости, и собрал и установил его локально, чтобы протестировать. Я мог «видеть» это в репо, но проект, который его использовал, получил указанную выше ошибку. Я установил стартовый POM на pom, поэтому JAR не было. Maven был совершенно прав, что этого не было в Nexus, но я не ожидал, что это будет, поэтому ошибка была, ммм, бесполезной. Замена стартового ПОМ на обычную упаковку и переустановка устранили проблему.
источник