Maven не может найти мои местные артефакты
Я не могу бежать mvn -o package потому что жалуется с
Система хранилища отключена, но артефакт com.liferay.portal:util-bridges:jar:6.1.20 недоступен в локальном хранилище.
Но я проверил свой локальный репозиторий, и этот артефакт там существует. Я также попытался решить проблему установки updatePolicy, чтобы она никогда не появлялась в файле settings.xml, но это не сработало.
4 ответа
До Maven 3.0.x Maven не отслеживал происхождение файлов в локальном хранилище.
Это может привести к проблемам со сборкой, особенно если вы собирали что-то, в котором был указан (теперь уже мертвый) очень испорченный репозиторий java.net2... Это изменение не только выпустило артефакты (крайне плохая и злая практика), но и опубликовало артефакты в те же координаты, что и артефакты на центральном, но различного содержания (невероятно злые)
Таким образом, вы могли бы выполнить сборку (поскольку у вас был commons-io:commons-io:2.0 из центрального), стереть локальное хранилище, и сборка не удалась (потому что теперь вы получаете commons-io:commons-io:2.0 от java.net2, которая был совершенно другой артефакт с разными зависимостями в поме) или наоборот.
Вышеуказанная ситуация является одним из драйверов для использования менеджера репозитория maven, поскольку это позволяет вам контролировать поднабор репозитория, который вы открываете в нисходящем направлении, и порядок, в котором артефакты разрешаются из нескольких репозиториев (обычно называемых правилами маршрутизации)
В любом случае, когда maven переключился на Aether в качестве уровня доступа к хранилищу, было принято решение начать отслеживать, откуда приходят артефакты.
Таким образом, в Maven 3.0.x, когда артефакт загружается из хранилища, maven оставляет _maven.repositories файл для записи, откуда файл был разрешен. Если вы строите проект, а в эффективный список репозиториев не входит местоположение, из которого был разрешен артефакт, то Maven решает, что это как если бы артефакт не находился в кэше, и попытается повторно разрешить артефакт...
В 3.0.x есть ряд ошибок... Самым важным является то, как offline обрабатывается... А именно: в автономном режиме maven 3.0.x считает, что нет репозиториев, поэтому всегда найдет несоответствие с _maven.repositories файл!!!
Обходной путь для Maven 3.0.x - удалить эти файлы из локального кэша, например
$ find ~/.m2/repository -name _maven.repositories -exec rm -v {} \;
Побочным эффектом является то, что вы теряете защиту, которую пытается обеспечить Maven 3.0.x.
Хорошей новостью является то, что Maven 3.1 будет иметь необходимое исправление (если мы когда-нибудь сможем собраться вместе и выпустить релиз)
В Maven 3.1 в автономном режиме _maven.repositories файл (частично) игнорируется, и есть также возможность игнорировать этот файл для онлайн-сборок (называемый устаревшим режимом)
На данный момент (1 июня 2013 г.) идет четвертая попытка выпустить релиз, отвечающий требованиям законодательства и тестирования... Итак, если предположить, что четвертый раз удачен, я надеюсь увидеть версию 3.1.0-alpha-1 выпускается через 3-4 дня... Но это может быть дольше, если учесть, что мы хотим дать изменениям в версии 3.1 достаточно времени, чтобы выдержать, чтобы гарантировать, что сборки не прерываются (произошли изменения в API, выставленном Случайность - API необходим плагину сайта и зависимости), от которого зависели авторы плагинов (хотя они и не должны были это делать), поэтому есть потенциал, хотя мы думаем, что мы охватили все основы)
Надеюсь, что это отвечает на ваш вопрос (и, возможно, еще несколько, вы не знали, что у вас есть;-))
Я также должен был удалить _remote.repositories таким же образом, как _maven.repositories, описанный выше. Я использую Maven 3.1.1
find ~/.m2/repository -name _remote.repositories -exec rm -v {} \;
У меня была эта проблема в Ubuntu Linux, когда я устанавливал локальные артефакты через скрипт оболочки. Решением было удаление локальных артефактов и их повторная установка "вручную" - вызов mvn install:install-file через терминал.
У меня была эта проблема, когда я использовал apache-maven-3.0.4, проблема исчезла сразу после перехода на apache-maven-3.3.1.