[
https://issues.apache.org/jira/browse/MNG-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6901:
--------------------------------
Fix Version/s: waiting-for-feedback
> 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
>
> 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)
