[EXPERIMENT] Proper remote repository scoping during dependency resolution #87
Conversation
| result.add( repository ); | ||
| if ( prepend ) | ||
| { | ||
| result.add( 0, repository ); |
There was a problem hiding this comment.
Wouldn't that reverse prepend?
There was a problem hiding this 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.
Introduce new method remote repository manager to allow make possible repositories to be added not only to TAIL but also to HEAD of remote repository list.
This PR is NOT meant for merge as is, is more just an example.