Как исправить неправильные контрольные суммы в моем репозитории Nexus?

У некоторых артефактов в моем локальном репозитории Nexus неверная контрольная сумма. Например (неверная контрольная сумма):

центральная кошка / org / codehaus / plexus / plexus-compiler-api / 1.8 / plexus-compiler-api-1.8.pom.sha1 95f3332c2bbace129da501424f297e47dd0e976b

vs (правильная контрольная сумма):

центральный sha1sum / org / codehaus / plexus / plexus-compiler-api / 1.8 / plexus-compiler-api-1.8.pom 4c2947f7e2d09b6e13da34292d897c564f1f9828

Похоже, в моем репозитории есть несколько артефактов, которые были загружены, когда была активна эта ошибка. .

Теперь у Maven Central правильная контрольная сумма (4c29 ...), но контрольные суммы в моем локальном репозитории Nexus остаются устаревшими. Я не знаю, как заставить мой локальный репозиторий проверить и / или повторно загрузить правильную контрольную сумму из центра.

Как правильно исправить мой локальный репозиторий. У этой проблемы не так много артефактов, поэтому я думаю, что могу (вручную) проверить, что они все еще существуют в центральном хранилище, и удалить их из моего локального репозитория. Они должны быть повторно кэшированы с правильными контрольными суммами. Есть ли способ лучше?

Обновление:

Я смотрел на это больше, и я почти уверен, что знаю, в чем источник моей проблемы. Один из артефактов, с которыми у меня возникли проблемы, это один (plexus-compiler-api: 1.8):

В моем репозитории и .pom, и .pom.sha1 имеют временную метку 29 марта 2010 года. В центральном месте .pom имеет временную метку 29 марта 2010 года, а .pom.sha1 - 21 апреля 2010 года. Я читал об обслуживании Nexus. Я предполагаю, что 21 апреля 2010 года Maven Central перестроила метаданные и проверила контрольные суммы, которые исправили неверный .sha1 для артефакта plexus-compiler-api: 1.8.

Согласно приведенной выше ссылке на Sonatype, я должен иметь возможность истечь кеши для Maven Central, и моя локальная установка будет извлекать новые копии чего-либо с более новыми временными метками, чем изначально кэшированные артефакты. Однако, судя по наблюдаемому мной поведению, я думаю, что он проверяет только временные метки для файлов артефактов, а не для файлов контрольной суммы.

Что касается моего локального репозитория Nexus, у меня самая последняя версия артефакта (29 марта 2010 г.), поэтому нет необходимости повторно загружать что-либо.

Я заметил, что моя версия Nexus довольно старая (1.5 против 1.9.1), поэтому я попробую обновить и посмотрю, справится ли новая версия лучше с истекающим сроком хранения кешей. Если нет, то я, наверное, посмотрю, что думают ребята из Sonatype (может, это ошибка?).


nexus maven-2
person Ryan J    schedule 22.04.2011    source источник

Ответы (2)


arrow_upward
11
arrow_downward

Нет, вы столкнетесь с определенным поведением Nexus и Maven.

Во-первых, истекающие кеши ничего не удаляют из локального кеша Nexus, они просто помечаются как «старые». Эффект пометки элементов как «старых» отображается при следующем входящем запросе тех же артефактов (если они не запрашиваются, «старые» артефакты просто остаются там). Это означает, что только истечение срока действия кеша не приведет к тому, что Nexus будет загружать удаленно измененные (более новые) файлы. Nexus никогда не загружается сам по себе (если мы не будем использовать индекс в этом обсуждении). Вы должны заставить клиента (Maven) запрашивать их - и это приведет к следующей цепочке действий: «кэшировать старое содержимое», удаленное обнаружение изменений и, наконец, повторная загрузка и кеширование нового файла.

Далее, здесь происходит то, что Maven, поскольку артефакт (файл JAR) не изменяется, даже не запрашивает файл контрольной суммы, следовательно, ничто не "запускает" "старую" помеченную повторную выборку контрольной суммы на стороне Nexus. Также следует отметить, что если мы говорим об выпущенных артефактах (а Maven Central действительно содержит только выпущенные артефакты), Maven никогда не будет повторно их проверять, если они не присутствуют в локальном репозитории (после того, как они были перенесены в локальный репозиторий, Maven никогда не будет пытаться повторно загрузить их). Это означает, что вам нужно удалить их из локального репозитория, чтобы быть уверенным, что Maven запросит их у Nexus, и, наконец, Nexus обнаружит изменения файла контрольной суммы на удаленном компьютере и сделает то, что вы действительно хотите.

Повторная загрузка должна произойти, например, если вы уничтожите локальный репозиторий Maven и перестроите его с чистым / пустым. В этом случае Maven должен запросить и артефакт JAR, и файл контрольной суммы, но из вашего описания неясно, как вы (или вы?) Вызывали Maven после истечения срока действия кешей на Nexus.

Попробуй это:

а) запустить кеши с истекшим сроком действия в репозитории прокси Nexus "Maven Central"

б) уничтожить локальный репозиторий (или просто перенаправить его в новую чистую папку, подделав ~ / .m2 / settings.xml

c) заставить Maven построить ваш проект, и он должен повторно получить файлы JAR и контрольной суммы (с использованием пустого / удаленного локального репозитория)

Надеюсь, это объясняет некоторые из того, что вы написали.

Ссылка на проблему JIRA, в которой обсуждается то же самое.

person Tamas Cservenak    schedule 18.05.2011

arrow_upward
4
arrow_downward

Это была ошибка.

Как объяснил Тамас, когда срок действия кеша прокси-репозитория истечет, Nexus проверит удаленный репозиторий на наличие новых временных меток. Локально кэшированные артефакты по существу помечаются как грязные, и проверка обновленных артефактов происходит по запросу, поскольку артефакты запрашиваются с локального сервера Nexus.

Nexus (1.9.1) делает предположение, что если метка времени артефакта не изменилась, контрольные суммы также должны остаться неизменными. В большинстве случаев это будет так, но из-за старой ошибки в Maven, которая развертывала артефакты с неверными контрольными суммами, в редких случаях артефакт может быть неизменным, но иметь обновленную контрольную сумму.

Я думаю, что лучший способ справиться с этим на данный момент - переместить все неверные контрольные суммы и позволить Nexus попытаться повторно решить их при следующем запросе:

mv сплетение-компилятор-api.pom.sha1 сплетение-компилятор-api-1.8.pom.sha1.bak

Спасибо за помощь Тамас.

person Ryan J    schedule 19.05.2011