Maven не может найти местный артефакт
Иногда maven жалуется, что определенная зависимость, которая создается и упаковывается локально, не может быть найдена в локальном репозитории при создании другого проекта, в котором она есть в качестве зависимости. Мы получаем ошибку как:
Не удалось выполнить цель в проекте X: не удалось разрешить зависимости для проекта X: не удалось найти Y в [хранилище архива], он был кэширован в локальном хранилище, разрешение не будет повторно предприниматься до тех пор, пока не истечет интервал обновления внутреннего или не будут выполнены принудительные обновления ->
Где X - это строящийся проект, а Y - предположительно отсутствующий артефакт. Если вы посмотрите в локальный репозиторий, там есть артефакт. Этот артефакт никогда не устанавливается в нашем хранилище архива, поэтому проблема основана исключительно на локальном хранилище.
Мы пробовали разные профили в файле settings.xml и, конечно, "mvn -U". Не приносят никакой пользы и не должны, потому что этот артефакт никогда не идет дальше, чем локальный репозиторий.
Единственные две вещи, которые, кажется, работают, - это очень долго ждать, пока maven улучшится, или полностью удалить локальный репозиторий. Предположительно, опция ожидания связана с вышеупомянутым интервалом обновления.
Мы столкнулись с этой проблемой с Maven 3.0.2 и 3.0.3. Мы используем Archiva 1.0.3 (но, опять же, это не должно быть фактором). Любая помощь будет принята с благодарностью.
18 ответов
Локальное хранилище Maven отслеживает происхождение артефактов, используя файл с именем "_maven.repositories" в каталоге артефактов. После его удаления сборка сработала. Этот ответ решил проблему для меня.
Поскольку варианты здесь не работают для меня, я поделюсь, как я решил это:
В моем проекте есть родительский проект (со своим собственным pom.xml), который имеет много дочерних модулей, один из которых (A) имеет зависимость от другого дочернего (B). Когда я пытался mvn package в A это не сработало, потому что B не удалось разрешить.
проведение mvn install в родительском каталоге сделали свою работу. После этого я мог сделать mvn package внутри А и только тогда он мог найти Б.
Даже в автономном режиме maven будет проверять удаленные репозитории, если для зависимости есть маркер _remote.repositories. Если вам нужно работать в автономном режиме, вам может потребоваться удалить эти файлы.
Простая команда оболочки ниже удаляет эти файлы маркеров. Это безопасно сделать, если вы используете для машины только автономный режим. Я бы НЕ делал это на машине, которая должна загружать файлы из Интернета.
Я использовал эту стратегию на сервере сборки, который отключен от сети. Мы должны перенести в него репозиторий, удалить файлы маркеров, а затем запустить в автономном режиме.
В Linux / Unix вы можете удалить файлы маркеров удаленного репозитория следующим образом:
cd ~/.m2
find . -name "_remote.repositories" -type f -delete
Мавен вспоминает, когда ничего не нашел. Ключ "разрешение не будет предпринято повторно, пока не истечет интервал внутреннего обновления или принудительные обновления ->"
Быстрое решение состоит в том, чтобы удалить локальный подкаталог "хранилище" для артефакта проблемы - при условии, что вы исправили проблему с ним.:)
mvn -U принудительно выполнит обновление из удаленного репозитория - снова, при условии, что вы заполнили удаленный репозиторий указанным артефактом.
Когда это случилось со мной, это было потому, что я слепо скопировал мой файл settings.xml из шаблона, и в нем все еще был пустой <localRepository/> элемент. Это означает, что при разрешении зависимостей не используется локальный репозиторий (хотя установленные артефакты все равно помещаются в расположение по умолчанию). Когда я заменил это на <localRepository>${user.home}\.m2\repository</localRepository> это начало работать.
Для * nix это было бы <localRepository>${user.home}/.m2/repository</localRepository>, Я полагаю.
Если у тебя есть <repositories/> определенный в вашем pom.xml, по-видимому, ваш локальный репозиторий игнорируется.
Поймай всех. Если упомянутые здесь решения не работают (в моем случае это происходит), просто удалите все содержимое из папки / каталога '.m2' и выполните mvn clean install,
Даже я столкнулся с этой проблемой и решил ее двумя способами:
1) В вашей среде IDE выберите проект и очистите все проекты, затем установите все зависимости maven, щелкнув правой кнопкой мыши проект -> перейти к maven, и в разделе "Обновить зависимости проекта" выберите все проекты одновременно, чтобы установить один и тот же. Как только это будет сделано, запустите конкретный проект
2) Иначе, что вы можете сделать, это проверить в pom.xml зависимости, для которых вы получаете ошибку, и сначала "mvn clean install" этих зависимых проектов, а также установить зависимости maven текущего проекта, в котором вы столкнулись с проблемой. Таким образом будут построены зависимости локального проекта и будут созданы фляги.
Я имел DependencyResolutionException в Ubuntu Linux, когда я установил локальные артефакты через скрипт оболочки. Решением было удаление локальных артефактов и их повторная установка "вручную" - вызов mvn install:install-file через терминал.
Это произошло потому, что у меня http вместо того https в этом:
<repository>
<id>jcenter</id>
<name>jcenter-bintray</name>
<url>https://jcenter.bintray.com</url>
</repository>
Проверьте , установлена ли для вашего артефакта Y упаковка "jar". Если вы определили это как "войну" из-за ошибки или копирования и вставки, будет показано, что это странное "было кэшировано в локальном репозитории, разрешение не будет повторяться, пока не истечет интервал обновления внутреннего или пока обновления не будут принудительно". Я ожидал чего-то вроде "артефакт Y - война, ожидается баночка".
В моем случае мне нужно было, чтобы проект Y был WAR для развертывания через Tomcat, а также должен был быть JAR, чтобы иметь возможность добавить его в качестве зависимости в проект X.
Итак, в проекте Y я добавил этот плагин для создания JAR вместе с WAR:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<attachClasses>true</attachClasses>
<classesClassifier>classes</classesClassifier>
</configuration>
</plugin>
И при добавлении зависимости проекта Y в проект X
pom.xml, Мне пришлось добавить
classifier:
<dependency>
<groupId>groupId.of.project.Y</groupId>
<artifactId>project.Y</artifactId>
<version>1.0-SNAPSHOT</version>
<classifier>classes</classifier>
</dependency>
Примечание: при сборке проекта Y вы увидите 2 упаковки в целевой папке:
project-Y.war а также
project-Y-classes.jar, поэтому при импорте вы указываете
classes классификатор для импорта JAR, а не WAR.
Я сталкиваюсь с подобной проблемой, когда мой новый проект зависит от oracle jdbc jar(которое я установил в своем локальном репозитории и хорошо работает для других проектов). Я попробовал параметр -U, удалив файл.lastupdate или весь каталог, и снова загрузил, но это не сработало. наконец, я удалил каталог и снова установил его локально, он работает.
Одна из ошибок, которые я обнаружил в Maven, - это когда я помещаю свой файл settings.xml в неправильный каталог. Он должен быть в папке.m2 под вашей домашней директорией пользователя. Убедитесь, что он находится в нужном месте (вместе с settings-security.xml, если вы его используете).
У меня была такая же ошибка по другой причине: я создал стартовый POM, содержащий наши "хорошие практики" зависимости, и собрал и установил его локально, чтобы протестировать. Я мог "увидеть" это в репо, но проект, который его использовал, получил указанную выше ошибку. Я установил стартовый POM на pom, поэтому JAR не было. Maven был совершенно прав, что этого не было в Nexus, но я не ожидал, что это будет, поэтому ошибка была, ммм, бесполезной. Замена стартового ПОМ на обычную упаковку и переустановка устранили проблему.
В моем случае мне пришлось добавить mavenLocal() в зависимость градиента корневого уровня
mavenCentral()
mavenLocal()
Вот подробное решение проблемы (не быстрое решение, но будет работать, если нет другого решения)
Вы возненавидите меня за эти слова, но это правда о проектах с открытым исходным кодом, таких как eclipse. Поскольку открытый исходный код является модульным и позволяет вам создавать и разрабатывать проект разными способами с помощью многих инструментов, таких как maven, spring boot, параметры для xml или groovy, различные обновления eclipse и т. Д. Проблема в том, что eclipse позволяет запускать проект с отсутствующими сборками maven, потому что IDE достаточно умен, чтобы разрешать зависимости с помощью remote_repository, где он хранит и перехватывает файлы jar, которые неправильно построены в проекте.
Из-за этой функции у вас могут быть проблемы с локальной сборкой, но точно так же, как с DNS-серверами; если решение не найдено в локальном каталоге, Eclipse будет искать решение в своем удаленном кешированном репозитории. Когда вы удаляете remote_repository и позволяете Maven восстановить его во второй раз, проект может в конечном итоге создать больше ошибок и не построить второй раз или, возможно, может восстановить отсутствующий кеш. Но это маловероятно.
Итак, длинный ответ, чтобы исправить ваше решение.
Это проблема архитектуры проекта!
РЕШЕНИЕ. Что вам нужно сделать, так это просмотреть файл pom.xml всего вашего зависимого проекта и папку зависимостей maven в вашем локальном проекте и попытаться разрешить все отсутствующие jar-файлы зависимостей в вашей папке зависимостей maven. Если у вас есть указанная библиотека, я предлагаю переместить эти jar-файлы в папку зависимостей maven вашего локального проекта.
Вам нужно работать над решением каждого дочернего проекта, а затем перейти к корневому проекту и исправить каждый проект с помощью Maven -> Build -> clean install (отметьте флажками «пропустить тесты» и «разрешить артефакты рабочей области») до тех пор, пока каждый проект строит с чистым успехом.
скорее всего, когда вы принудительно обновите все свое решение для всех своих проектов, вы получите список ошибок, которые у вас есть автоматически разрешить в среде IDE. Автоматическое решение будет относиться к простой ссылке для решения проблемы. Но для развертывания вам нужно вручную исправить проект, потому что Eclipse, Spring и Maven будут хорошо работать вместе, но, возможно, есть несколько вещей, с которыми они не согласны. Итак, вам нужно играть дипломатом в таких ситуациях и разбираться в этом.
Это печальная правда.
В общем, у меня есть список проблем в моем проекте. У меня такая проблема. Сгенерированный военный файл имеет пустые папки jar, и сборка не будет чистой без ошибок, если я не заставлю ее. Сгенерированный файл WAR вызовет ошибку 404 при производстве сервера tomcat, а мое приложение angular выдаст ошибку Cors-Error при выполнении API.
Все ошибки в моем внешнем проекте искусственны, потому что корень всех проблем - это сгенерированный файл WAR. Он не генерировался с зависимостями, основной проект не выполнялся в tomcat, а сервер tomcat не может запустить инициализатор spring для развертывания политики cors на сервере, чтобы мое приложение angular могло взаимодействовать. Но в целом среда разработки работает без проблем.
Так что это мое долгое решение для этой темы.