[jira] [Comment Edited] (MRESOLVER-133) Improve resolver performance by using breadth-first search

["Michael Osipov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520023#comment-17520023 ] 

Michael Osipov edited comment on MRESOLVER-133 at 4/10/22 8:17 AM:
-------------------------------------------------------------------

Is there a way for me to obtain the proposed  resolver and test with my own use cases?


was (Author: cannucklehead):
Is there a way for me to obtain the proposed  resolver and test with my own use cases?

 

 

> 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)