Reputation: 3749
I'm trying to get the netty-codec-hhtp going in my maven project. I have a completely standard Sonatype Nexus set up to proxy requests to Maven Central.
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.0.9.Final</version>
</dependency>
This fails when building using maven. If I search for it manually in Nexus I find it, but if I go to download the jar it tells me:
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)
What does this even mean, why am I getting it, and maybe more importantly, how do I fix it? I am using Nexus 2.5.0-04 with Maven 3.0.4
Downloading other artifacts seems to work just fine.
Upvotes: 9
Views: 7136
Reputation: 380
I faced the same issue when configuring a bridge between 2 Nexus.
In the first:
Using the first Nexus, each time I requested a dependency only present in the 2nd, I encountered the Automatic routing filter rejected remote request for path...
exception.
As mentionned by Tamas, this issue comes from the Routing >> Discovery
feature that was enabled in my 2 proxy repos, that were targeting remote Nexus repository groups.
Once disabled, the issue was solved.
The exact explanation of this need is in some way explained in the official Sonatype documentation for Repository Management with Nexus, in chapter 6.4.1 on Automatic Routing:
The Routing tab for a proxy repository displayed in Figure 6.18, “Automatic Routing for a Proxy Repository” contains the Discovery section. It displays the Status and a more detailed Message about the prefix file access. The Last run field displays the date and time of the last execution of the prefix file discovery. Such an execution can be triggered by pressing the Update now button. Otherwise, the Update Interval allows you to trigger a new discovery every one, two, three, six, nine or twelve hours or as a daily or weekly execution.
[...]
For a proxy repository, the prefix file is either downloaded from the remote repository or a generation is attempted by scraping the remote repository. This generation is not attempted for remote Nexus repository groups, since they are too dynamic in nature and should not be proxied directly. Scraping of hosted or proxy repositories as well as Subversion-based repositories is supported.
Regards, Thomas
Upvotes: 1
Reputation: 751
UPDATE: This turned out to be an issue with CDN configuration that should now be resolved. The steps below for forcing and/or disabling remote discovery are left for reference.
It means that Automatic Routing for Central is active, and that the discovered rules does not contain io.jetty
as allowed prefix.
This should not happen, as the default configuration should update the rules on daily basis (as seen on screenshot below, showing the default Automatic Routing configuration for Central).
The remedy is to either force the update of rules (I did check, prefix /io
is among rules Central publishes), or disable remote discovery completely.
Try steps as shown below on screenshot:
Upvotes: 14
Reputation: 5094
From Repository Management with Nexus - 6.4. Managing Routing:
Routing can be considered the internal activities Nexus perform in order to determine, where to look for a specific component in a Maven repository. The routing information has an impact on the performance of component retrieval as well as determining the availability of components.
(...)
Automatic Routing is handled by Nexus on a per repository basis.
(...)
The Routing information consists of the top two levels of the directory structure of the repository and is stored in a prefixes.txt file. It allows Nexus to automatically route only component requests with the corresponding groupId values to a repository to avoid unnecessary index or even remote repository access.
Since Maven central repo contains that artifact I assume that the automatic routing rules forbids remote download for that artifact. The error message you posted suggests it also.
You can read how to add a routing rule under 6.4.2. Manual Routing Configuration. If my assumption is correct, this situation shoud be resolved by adding an inclusive
rule type with ^/io/netty/.*
route for central repo.
Upvotes: 1