cstamas commented on a change in pull request #87:
URL: https://github.com/apache/maven-resolver/pull/87#discussion_r553925217
##########
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRemoteRepositoryManager.java
##########
@@ -201,7 +210,14 @@ public DefaultRemoteRepositoryManager
setChecksumPolicyProvider( ChecksumPolicyP
}
}
- result.add( repository );
+ if ( prepend )
+ {
+ result.add( 0, repository );
Review comment:
Project model build invokes this method with "false", so all as before:
the list of repositories are in same exact order as before. If your project
defines prj-repo1, prj-repo2, prj-repo3 the result will be [prj-repo1,
prj-repo2, prj-repo3] (let's neglect central from super pom for now, but it is
last).
Now, if we call level0 the project model, and level1 the 1st sibling
dependency of level0, and level2 the first sibling of level1, then: as
ModelResolver is recursively being cloned/copied, and modified (by adding
reposes of downloaded and parsed POMs), AND if we assume each level is adding
new repo (as in my example), you will end up with these lists in different
instances of ModelResolver on each level:
level1: [level1-repo, prj-repo1, prj-repo2, prj-repo3]
level2: [level2-repo, level1-repo, prj-repo1, prj-repo2, prj-repo3]
and so on.
Maybe the name is not clear, but that's above is the idea.
##########
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultRemoteRepositoryManager.java
##########
@@ -201,7 +210,14 @@ public DefaultRemoteRepositoryManager
setChecksumPolicyProvider( ChecksumPolicyP
}
}
- result.add( repository );
+ if ( prepend )
+ {
+ result.add( 0, repository );
Review comment:
Project model build invokes this method with "false", so all as before:
the list of repositories are in same exact order as before. If your project
defines prj-repo1, prj-repo2, prj-repo3 the result will be [prj-repo1,
prj-repo2, prj-repo3] (let's neglect central from super pom for now, but it is
last).
Now, if we call level0 the project model, and level1 the 1st sibling
dependency of level0, and level2 the first sibling of level1, then: as
ModelResolver is recursively being cloned/copied, and modified (by adding
reposes of downloaded and parsed POMs), AND if we assume each level is adding
new repo (as in my example), you will end up with these lists in different
instances of ModelResolver on each level:
level1: [level1-repo, prj-repo1, prj-repo2, prj-repo3]
level2: [level2-repo, level1-repo, prj-repo1, prj-repo2, prj-repo3]
and so on.
In short, as you "dive in" recursively into resolving dependencies, you want
"nearest" repo to prevail, and those are prepended to list...
Maybe the name is not clear, but that's above is the idea.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
