torsten-liermann opened a new issue, #2225:
URL: https://github.com/apache/maven-resolver/issues/2225

   ### Affected version
   
   1.9.27, 2.0.24, master at b67aa7041f93a68a4e1dae6e592bbf047cab47d6 
(2.0.25-SNAPSHOT); also 2.0.23 as bundled with Maven 4.0.0-rc-7
   
   ### Bug description
   
   `RepositorySystem.newResolutionRepositories` selects a mirror again for 
repositories that already list mirrored repositories. A single `*` mirror is 
enough: calling it a second time on its own result yields `corp[corp[central]]` 
instead of `corp[central]` (notation: mirror[mirrored repositories]).
   
   Minimal example, with a `RepositorySystem system` and a 
`DefaultRepositorySystemSession session` that has a local repository manager:
   
   ```java
   session.setMirrorSelector(new DefaultMirrorSelector()
           .add("corp", "https://corp.invalid/";, "default", false, false, "*", 
"*"));
   RemoteRepository central = new RemoteRepository.Builder(
           "central", "default", "https://central.invalid/";).build();
   List<RemoteRepository> prepared = system.newResolutionRepositories(
           session, Collections.singletonList(central));
   List<RemoteRepository> repeated = system.newResolutionRepositories(session, 
prepared);
   ```
   
   `DefaultRepositorySystem.newResolutionRepositories` passes its whole input 
to `aggregateRepositories` with `recessiveIsRaw=true` 
([2.0.24](https://github.com/apache/maven-resolver/blob/a9dc49593c3023c7c3fde50d0df55223dda98a04/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositorySystem.java#L583-L589),
 
[1.9.27](https://github.com/apache/maven-resolver/blob/bac936257dc7daf7eb14b7082551a054f16641db/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRepositorySystem.java#L416-L423)).
 `DefaultRemoteRepositoryManager` then calls `MirrorSelector.getMirror` for 
every input repository, regardless of its mirrored repositories 
([2.0.24](https://github.com/apache/maven-resolver/blob/a9dc49593c3023c7c3fde50d0df55223dda98a04/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRemoteRepositoryManager.java#L141-L142),
 
[1.9.27](https://github.com/apache/maven-resolver/blob/bac936257dc7daf7eb14b7082551a054f16641db/maven-res
 
olver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRemoteRepositoryManager.java#L135-L136)).
 The SPI defines `recessiveIsRaw=true` as "the recessive repository definitions 
have not yet been subjected to mirror, proxy and authentication settings" 
([2.0.24](https://github.com/apache/maven-resolver/blob/a9dc49593c3023c7c3fde50d0df55223dda98a04/maven-resolver-impl/src/main/java/org/eclipse/aether/impl/RemoteRepositoryManager.java#L44-L45)).
 The Javadoc of `newResolutionRepositories` speaks of "repository prototypes" 
and "a bare repository definition" 
([2.0.24](https://github.com/apache/maven-resolver/blob/a9dc49593c3023c7c3fde50d0df55223dda98a04/maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystem.java#L294-L313))
 and does not say what happens to input that already lists mirrored 
repositories.
   
   Expected: the selected mirror and its original provenance are kept. Actual: 
mirror selection runs again against the mirror's own ID and URL. With 
`DefaultMirrorSelector`, the two calls give the following on 1.9.27, 2.0.24 and 
master:
   
   | Mirrors (`id` → `mirrorOf`) | Input | First call | Second call |
   | --- | --- | --- | --- |
   | `corp` → `*` | `central` | `corp[central]` | `corp[corp[central]]` |
   | `central-exception` → `central`; `corporate` → `*` (same with 
`external:*`) | `central` | `central-exception[central]` | 
`corporate[central-exception[central]]`, URL of `corporate` |
   | `corp-http` (HTTP URL) → `central`; Maven's default 
`maven-default-http-blocker` → `external:http:*` | `central` | 
`corp-http[central]` | `maven-default-http-blocker[corp-http[central]]`, 
blocked |
   | `corp` → `external:*,!foo`; Maven's default blocker | `foo` (HTTP URL) | 
`maven-default-http-blocker[foo]`, blocked | 
`corp[maven-default-http-blocker[foo]]`, not blocked |
   
   So a wildcard mirror can replace an exact mirror, a working HTTP mirror can 
become blocked, and a repository blocked by the default blocker can be 
redirected to a mirror that is not blocked.
   
   Maven 4.0.0-rc-7, which bundles Resolver 2.0.23, runs into this in a plain 
build. Its project builder hands the request repositories, which already carry 
the mirror chosen from `settings.xml`, to the model builder 
([DefaultProjectBuilder](https://github.com/apache/maven/blob/6d8f301b38af7399b36b862969d520974944f0b9/impl/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java#L1136-L1138)).
 Parent POM resolution goes through `session.resolveArtifact` 
([DefaultModelResolver](https://github.com/apache/maven/blob/6d8f301b38af7399b36b862969d520974944f0b9/impl/maven-impl/src/main/java/org/apache/maven/impl/resolver/DefaultModelResolver.java#L179-L180))
 to `toResolvingRepositories` 
([DefaultArtifactResolver](https://github.com/apache/maven/blob/6d8f301b38af7399b36b862969d520974944f0b9/impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultArtifactResolver.java#L95-L96)),
 which calls `newResolutionRepositories` 
([AbstractSession](https://github.com/apache/maven/bl
 
ob/6d8f301b38af7399b36b862969d520974944f0b9/impl/maven-impl/src/main/java/org/apache/maven/impl/AbstractSession.java#L286-L289)).
 `mvn validate` on a project whose parent POM has to be downloaded, using the 
mirrors of rows 2 to 4 in `settings.xml` and the default global settings:
   
   | Setup | Maven 3.9.16 and 3.10.0 | Maven 4.0.0-rc-7 |
   | --- | --- | --- |
   | Row 2, parent only in `central-exception` | parent from 
`central-exception`, success | parent requested from `corporate`, 
`Non-resolvable parent POM` |
   | Row 3, parent served by `corp-http` over plain HTTP | parent from 
`corp-http`, success | `corp-http` not contacted, `Blocked mirror for 
repositories: [corp-http (…)]` |
   | Row 4, `foo` declared in the POM, parent only in `corp` | `Blocked mirror 
for repositories: [foo (…)]` | parent from `corp`, success |
   
   For row 2, rc-7 prints:
   
   ```text
   [INFO] Downloading from corporate: 
file:///…/repo-wild/test/parent/1/parent-1.pom
   [ERROR]     Non-resolvable parent POM: The following artifacts could not be 
resolved: test:parent:pom:1 (absent): Could not find artifact test:parent:pom:1 
in corporate (file:///…/repo-wild) …
   ```
   
   With `-X`, the only Resolver mirror decision logged is `Using mirror 
corporate (file:///…/repo-wild) for central-exception (file:///…/repo-exact).` 
With the Resolver jars of rc-7 replaced by a master build with the change 
proposed below, all three builds give the Maven 3.9.16/3.10.0 results; with a 
build of unchanged master they behave as rc-7.
   
   In the Maven 3.9.16 (Resolver 1.9.27) and 3.10.0 (Resolver 2.0.24) 
distributions, no class outside Resolver references 
`newResolutionRepositories`. The core callers of `aggregateRepositories(…, 
true)`, `ProjectModelResolver` and `DefaultModelResolver`, pass a single 
repository freshly converted from the POM, and the prepared external list with 
`false`. Plugins and extensions that pass already prepared repositories to 
`newResolutionRepositories` get the repeated selection on both lines.
   
   I propose to skip mirror selection for repositories supplied by the build 
that already list mirrored repositories, to keep proxy and authentication 
selection for them, and to keep the current selection for repositories declared 
by a remote artifact descriptor. A pull request with regression tests will 
follow; a separate backport for 1.9.x is prepared.
   
   Context: [WildFly Maven Plugin PR 
#783](https://github.com/wildfly/wildfly-maven-plugin/pull/783#discussion_r4356688599),
 where the plugin passes repositories to `newResolutionRepositories` and 
reporting this behaviour here was suggested.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to