[ https://issues.apache.org/jira/browse/MNG-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181633#comment-17181633 ]
Michael Osipov commented on MNG-6901: ------------------------------------- No, I did not. Next time please write explicit commands. Going through... > Maven dependency fails if the parent entire history cannot be resolved. > ----------------------------------------------------------------------- > > Key: MNG-6901 > URL: https://issues.apache.org/jira/browse/MNG-6901 > Project: Maven > Issue Type: New Feature > Components: Dependencies > Affects Versions: 3.5.0, 3.6.1, 3.6.2, 3.6.3 > Reporter: Gregory Ducharme > Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: mvnbaddeps.zip > > > When any 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 ... > > I believe this condition arises because maven unnecessarily 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. > > 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.3.4#803005)