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

В одном из моих проектов 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файлы, соответствующие ошибочным артефактам (например, ~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml).После того, как эти файлы удалены, следующий mvn вызов выполняется правильно;файлы метаданных восстанавливаются этим вызовом (предположительно, как часть процесса проверки моих репозиториев / зеркал верхнего уровня на наличие обновленных артефактов), и мне снова выдаются ошибки, описанные выше, до тех пор, пока я снова не удалю файлы метаданных.

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

Мысли?

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

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

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

> 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

После того, как локальный репозиторий заблокирован (путем генерации файлов maven-metadata-local.xml, AFAICT), ни одна сборка не пройдет этап разрешения зависимостей.

Running 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 и др. существует , как и /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom.Полностью озадачен.На данный момент, я предполагаю, что это ошибка в Maven 3 (или некоторой базовой библиотеке), теперь, когда я вижу, что 2.2.1 чист.

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

Ответы [ 3 ]

5 голосов
/ 18 августа 2011

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

0 голосов
/ 08 мая 2011

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

0 голосов
/ 07 мая 2011

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

...