Maven не удается до Maven-метаданные local.xml файлы не будут удалены [Maven-Вызывающий-плагин, связанные с]

Question

В одном из моих проектов 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 выполняется правильно; файлы метаданных восстанавливаются этим вызовом (предположительно как часть процесса проверки моих восходящих репозиториев/зеркал для обновленных артефактов), и я снова получаю вышеуказанные ошибки, пока я снова не удалю файлы метаданных.

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

Мысли?

Update: Похоже, это maven-invoker-plugin (который эти сборки используют для тестирования интеграции общего назначения), который производит эти maven-metadata-local.xml файлы. Я не использую локальное репо только для тестирования интеграции as described here, потому что это приводит к повторной загрузке всех транзитивных зависимостей (unless you want to maintain an integration-specific settings.xml file!!!). Я использовал плагин invoker с множеством других проектов таким образом с хорошими результатами - конечно, никогда не сталкиваясь с клингом локального репозитория в этом процессе.

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

Вот один из проектов в вопросе: 1.3.0-compat branch of rummage. Чтобы воспроизвести:

> 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 

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

Запуск 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 чист.

Обновление 3Bug report filed with Maven project.

Answer 1

Эта проблема решена в эфире 1.12, на один оборот выше библиотеки эфира 1.11, которая поставляется с Maven 3.0.3. Замена эфира 1.11 на 1.12 в установке Maven приводит к ожидаемому поведению (as noted in the bug I filed). Здесь надеется, что Maven 3.0.4 выпущен с эфиром 1.12 ASAP. :-)

Answer 2

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

Answer 3

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