[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520153#comment-17520153
]
wei cai commented on MRESOLVER-133:
-----------------------------------
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equals to
https://issues.apache.org/jira/browse/MNG-7049, right? Just to fix the
unnecessary poms downloadings when comes to resolve a version range?
The BFS + Skipper is in BFDependencyCollector, as you can see below it will
do skip resolution of lower versions, however it does not help skip pom
downloadings.
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498]
To fix the unnecessary pom downloadings, let's check the code:
# maven downloads metadata.xml to figure out all available versions for the
version range
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384]
# Download all poms one by one
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394]
The issue is in #2. Maven just downloads all poms matching thee version range,
as Ivan pointed out in above threads, we can just reverse the version list and
then break if a version is resolved sucessfully.
Fired initial PR:
[https://github.com/apache/maven-resolver/pull/163]
Feel free to edit the PR if you would like to modify.
> Improve resolver performance by using breadth-first search
> ----------------------------------------------------------
>
> Key: MRESOLVER-133
> URL: https://issues.apache.org/jira/browse/MRESOLVER-133
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Affects Versions: 1.4.2
> Reporter: Gregory Ducharme
> Priority: Major
> Attachments: mvnbaddeps.zip
>
>
>
> I believe the maven resolver is unnecessarily inefficient because it performs
> a depth-first search of components to resolve dependencies. Consider the case
> when dependencies use version ranges, the user intent is for maven to resolve
> with the highest versions of dependencies that satisfy all constraints. If
> maven were to use a breadth-first search (and terminate searching as soon as
> a solution is found) then in many cases a valid set of dependencies can be
> resolved (at the top of the version ranges) without requiring that all
> historical versions are resolvable. One should get the same answer with both
> depth-first and breadth first strategies, but with the breadth-first approach
> not being vulnerable to a missing parent POM somewhere in history making it
> impossible to build the head of code. Additionally, I suspect that
> breadth-first would be faster and use less memory than depth first.
>
> Additionally the depth-first approach has a weakness that when ny version of
> a parent pom of a component referenced in a dependency tree of another
> component is missing maven fails to resolve dependencies. One get a message
> of the form:
> Failed to execute goal on project module: Could not resolve dependencies for
> project baddepdemo.project2:module:jar:1: Failed to collect dependencies ...
>
> Currently the only way to resolve this issue is one of three ways:
> 1) restore a missing parent POM into the repository history, or
> 2) delete all modules associated with the missing parent POM from the
> repository
> 3) manually adjust version ranges in consumer dependencies to exclude the
> bad versions of dependencies that refer to the missing parent POM.
>
> What I would like is a configuration switch that would allow one to select
> between the two search strategies So that the manual interventions described
> above are not required.
>
> I have include a zip file that include the minimal projects needed to
> demonstrate the dependency resolution problem:
> project 1 has a module and parent pom.
> project 2 is a single pom that has a dependency on the module in project 1.
> Project 2 uses a dependency range [1,) that indicates that the latest version
> of project1's module is to be used.
> If one builds two versions (1 and 2) of project 1, project2 will resolve to
> use version 2 as expected. However if you delete the parent pom of project1
> from the repository maven cannot resolve dependencies and fails. If the
> version range in project 2 is changed to [2,) then the expected behavior is
> observed.
> The zip file contains a shell script (demo.sh) that can be run without
> parameters to demonstrate the behavior when all versions are present in the
> repository. Run it with 1 as a parameter (the lower end of the version range
> used in project2) and the script will delete the parent pom from project 1
> and the error condition will be demonstrated. Run it with 2 and maven will
> resolve dependencies as version1 of project1 is explicitly excluded from the
> dependency resolution process.
>
> I am also willing to look at the source and propose a patch, but I would need
> guidance on which modules/source I should look at.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
