Following mirror configuration from settings.xml

We're experiencing this problem, too.
We have our own Sonatype Nexus repository setup behind the firewall, which is defined in the mirrors section of the settings.xml. Standard Maven operations work fine, no proxy settings needed in the settings.xml file.

When executing mvn archetype:generate, however, the error "Connection to http://repo1.maven.org refused" is given. (Similar symptoms to ARCHETYPE-202, but different cause.) The archetype plugin should NOT be trying to connect to this URL directly – instead, it should be using the mirror we have defined.

Based on my limited digging and Maven plugin knowledge:

I think fixing this is tough (well, it involves a difficult decision) because there appears to be a design mismatch in how the archetype plugin operates and how Maven itself operates. Maven operates based on a LIST of remote repositories: the user may or may not use central, and all servers are filtered through the mirrors list to arrive at a final list of remote repositories. However, in the final remote repository list, knowledge of which repository maps to central (if any) is lost.

The archetype plugin is hard-coded to look at exactly one remote repository, central. There's no good way to resolve or map central to some other repository (not without some bad hacking) – exactly which remote repository from the list should map to central is unknown.

So I think the ultimate question is: Should the archetype plugin really be hard-coded to look directly at one repository, central? Why not utilize the list of remote repositories that core Maven already provides (already filtered through the mirrors), searching each one by one?

Attached is a patch for the DefaultArchetypeSelector class.
A new dependency on "org.apache.maven:maven-compat:3.0.4" is needed in order to reuse existing Mirror processing logic.
The patch trades a hard-coded URL to central (which is bad) with a hard-coded server id of "central" (which is also bad). Not an ideal solution, but certainly no worse off than today...

Unfortunately, the getMirrors() method of the existing ArchetypeGenerationRequest argument returns an empty list of Mirrors and I don't know why or what the proper way would be to resolve it. Perhaps if somebody could jump in and solve the other half of this puzzle, we could get a workable solution...

I agree. Trading the hardcoded url for the repo/server id is good. And then use the standard Maven logic for using the correct mirror.

As a note, there's A LOT of docs to update if we implement this change. It is stated in several pages that the central repo url is used by default, which should be changed to state that the url defined by the (magic) repo id 'central' is used.

I've created ARCHETYPE-427 which is about changing the current behavior with one hard-coded repo url.

Now seeing a similar issue - which may or may not be related.

mvn archetype:generate -DarchetypeCatalog=http://nexus.magnolia-cms.com/content/groups/enterprise

The first time I execute the command, I can access the catalog - which is hinting that my settings.xml are taken into account. The second time, I do get a permission issue.

If I remove my settings.xml, the first time fails, somehow confirming they're used - once, but not twice ? I have NO IDEA what the difference between the first and the second run is, since I don't have cd into the newly created project, so there is NO pom.xml to interfere with mvn right there ... Puzzling !