Не удается разрешить зависимость Maven 3 до тех пор, пока не будут удалены файлы maven-metadata-local.xml [связанные с maven-invoker-plugin]

В одном из моих проектов Maven разрешение зависимостей будет выполнено один раз, а затем завершится неудачей для последующих попыток сборки:

[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing, no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency information available

… и т. д., до тех пор, пока не удаляю файлы maven-metadata-local.xml, соответствующие ошибочным артефактам (например, ---- +: = 2 = + ----). После удаления этих файлов следующий вызов ~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml будет выполнен правильно; файлы метаданных восстанавливаются этим вызовом (предположительно, как часть процесса проверки моих репозиториев /зеркал верхнего уровня на предмет обновленных артефактов), и мне снова выдаются ошибки, описанные выше, до тех пор, пока я снова не удалю файлы метаданных.

Это влияет на несколько проектов, хотя, как представляется, оно ограничено определенным набором зависимостей. Я полагаю, что мог бы стать ядерным и взорвать свой локальный репо, но я бы хотел понять, в чем проблема.

Мысли?

Обновление . Похоже, это maven-invoker -plugin (который эти сборки используют для тестирования интеграции общего назначения), который создает эти файлы mvn. Я не использую локальное хранилище только для интеграционного тестирования как описано здесь , просто потому, что это вызывает повторную загрузку всех транзитивных зависимостей (, если вы не хотите поддерживать специфичный для интеграции файл settings.xml !!! ). Таким образом, я использовал плагин invoker для множества других проектов с хорошими результатами - конечно, никогда не сталкивался с заклинившим локальным репозиторием в этом процессе.

Обновление 2 . Хорошо, это можно повторить даже после запуска с полностью свежим локальным репозиторием. Это на OS X, Java 1.6.0_24 с Maven 3.0.3; обратите внимание, что Maven 2.2.1 НЕ демонстрирует эту проблему.

Вот один из рассматриваемых проектов: 1.3.0-compat ветка рыться . Воспроизвести:

maven-metadata-local.xml

После того, как локальный репозиторий заблокирован (путем генерации файлов > mvn clean test # no error -- can run this and other builds that don't involve maven-invoker-plugin all day w/o problems > mvn clean integration-test # FAIL: "Could not resolve dependencies", with warnings as noted above > mvn clean test # FAIL: "Could not resolve dependencies", with warnings as noted above , AFAICT), ни одна сборка не пройдет мимо разрешения зависимости стадия.

Выполнение maven-metadata-local.xml показывает строки, подобные этой, для каждого артефакта, который позже явно не найден:

mvn -X

Конечно, [DEBUG] Verifying availability of /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from [] и др. существует , как и /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar. Полностью озадачен. На данный момент, я предполагаю, что это ошибка в Maven 3 (или некоторой базовой библиотеке), теперь, когда я вижу, что 2.2.1 чист.

Обновление 3 Отчет об ошибках, поданный в проект Maven .

7 голосов | спросил cemerick 7 Mayam11 2011, 00:36:39

3 ответа


0

Эта проблема решена в эфире 1.12, на одну версию выше библиотеки эфира 1.11, которая поставляется с Maven 3.0.3. Замена эфира 1.11 на 1.12 в процессе установки Maven приводит к ожидаемому поведению (, как отмечено в сообщенной мной ошибке ). Надеемся, что Maven 3.0.4 выпущен с эфиром 1.12 как можно скорее. : -)

ответил cemerick 18 PM00000030000003031 2011, 15:40:30
0

вы не упомянули, что, возможно, пытались, поэтому, возможно, вы не пробовали это: добавление опции -U для принудительного обновления? (хотя, возможно, эта опция -U актуальна только для SNAPSHOT ...)

ответил Laurent Petit 7 Mayam11 2011, 01:52:44
0

Я видел похожие ошибки, вызванные поврежденными файлами в моем локальном хранилище. Например, если загрузка не удалась на полпути или файл в удаленном хранилище изменился после того, как я его загрузил. Удаление затронутых каталогов в ~/.m2 исправило это.

ответил Stuart Sierra 8 Mayam11 2011, 01:46:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132