Автоматический фильтр маршрутизации отклонил удаленный запрос - Nexus

Question

Я пытаюсь получить netty-codec-hhtp в моем проекте maven. У меня есть полностью стандартный Sonatype Nexus, настроенный на запросы прокси-сервера Maven Central.

<dependency> 
    <groupId>io.netty</groupId> 
    <artifactId>netty-codec-http</artifactId> 
    <version>4.0.9.Final</version> 
</dependency> 

Это не удается при строительстве с использованием maven. Если я искать его вручную в Nexus я его найти, но если я иду, чтобы загрузить банку он говорит мне:

404 - Not Found 
Automatic routing filter rejected remote request for path /io/netty/netty-codec-http/4.0.9.Final/netty-codec-http-4.0.9.Final.jar from M2Repository(id=central) 

Что это вообще значит, почему я получаю это, и, возможно, более важно, как сделать Я чиню это? Я использую Nexus 2.5.0-04 с Maven 3.0.4

Загрузка других артефактов, кажется, работает нормально.

Answer 1

UPDATE: Это оказалось проблемой с конфигурацией CDN, которая должна быть разрешена. Следующие шаги для принудительного и/или отключения удаленного обнаружения оставлены для справки.

Это означает, что автоматическая маршрутизация для центра активна и что обнаруженные правила не содержат io.jetty в качестве разрешенного префикса.

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

Средство правовой защиты - либо принудительное обновление правил (я проверил, префикс /io входит в число центральных изданий), либо полностью отключить удаленное обнаружение.

шаги Try, как показано ниже на скриншоте:

Answer 2

Repository Management with Nexus - 6.4. Managing Routing От:

маршрутизации можно считать внутренней деятельности Nexus выполнить для того, чтобы определить, где искать для конкретного компонента в репозитории Maven. Информация о маршрутизации влияет на производительность поиска компонентов, а также на определение доступности компонентов.
(...)
Автоматическая маршрутизация выполняется Nexus на основе каждого хранилища.
(...)
Информация о маршрутизации состоит из двух верхних уровней структуры каталогов репозитория и хранится в файле prefixes.txt. Он позволяет Nexus автоматически маршрутизировать только запросы компонентов с соответствующими значениями groupId в репозиторий, чтобы избежать ненужного индекса или даже удаленного доступа к репозиторию.

С Maven центральных репо contains that artifact Я предполагаю, что автоматические правила маршрутизации запрещает удаленную загрузку для этого артефакта. Вышеупомянутое сообщение об ошибке также предлагает.

Вы можете прочитать, как добавить правило маршрутизации под 6.4.2. Manual Routing Configuration. Если мое предположение верно, эту ситуацию можно решить, добавив тип правила inclusive с маршрутом ^/io/netty/.* для центрального репо.

Answer 3

я столкнулся с той же проблемой при настройке моста между 2 Nexus.

В первом:

1. Я добавил 2 прокси репо, таргетинг 2 группы общественных Репо в секунду,
2. затем агрегируют эти 2 прокси репо в новой группе,
3. , что я, наконец, добавил в список репо первой Nexus группы общественного репо

Используя первый Nexus, каждый раз, когда я просил зависимость присутствует только в 2-ом, я столкнулся Automatic routing filter rejected remote request for path... исключение.

Как упоминался на Тамас, этот вопрос исходит из Routing >> Discovery функции, которая была включена в моей 2 прокси-операции РЕПО, которые были показаны удаленных хранилища Nexus группы. После того, как проблема была отключена, проблема была решена.

Точное объяснение этой потребности каким-то образом объяснено в официальной документации Sonatype для Repository Management with Nexus, в разделе 6.4.1 на автоматической маршрутизации:

Вкладка Routing для хранилища прокси показано на рисунке 6.18, «Автоматическая маршрутизация для репозитория прокси» содержит Discovery раздел. Он отображает состояние и более подробное сообщение о доступе к префиксу . В поле последнего запуска отображается дата и время последнего выполнения обнаружения файла префикса. Такое выполнение может быть вызвано , нажав кнопку «Обновить сейчас». В противном случае обновление Interval позволяет запускать новое обнаружение каждый, два, три, шесть, девять или двенадцать часов или ежедневное или еженедельное выполнение.

[...]

Для хранилища прокси-файл префикса загруженный из удаленного хранилища или поколение попытки путем соскоба удаленного хранилище. Это поколение не предпринимается для удаленных Nexus группы репозитория, так как они слишком динамичны по своей природе и не должны быть проксированными непосредственно. Также поддерживается очистка репозиториев размещенных или прокси-серверов, а также в качестве хранилищ на основе Subversion.

С уважением, Томасом