maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Osipov (Jira)" <>
Subject [jira] [Commented] (MRESOLVER-133) Maven dependency fails if the parent entire history cannot be resolved.
Date Fri, 21 Aug 2020 09:49:00 GMT


Michael Osipov commented on MRESOLVER-133:

First of all, this belongs to Resolver, issue moved. Have a look at the exception:

Caused by: org.eclipse.aether.collection.DependencyCollectionException: Failed to collect
dependencies at baddepdemo.project1:module:jar:1
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies (

How is this supposed to work? Resolver sees your range request. To solve this, it requires
{{maven-metadata.xml}} to find the limited upper range bound. Just because 2 is installed,
it does not mean it is the best available version. It may exist version 3 or newer remotely.

In my opinion, this works as designed.

[~khmarbaise], WDYT?

> Maven dependency fails if the parent entire history cannot be resolved.
> -----------------------------------------------------------------------
>                 Key: MRESOLVER-133
>                 URL:
>             Project: Maven Resolver
>          Issue Type: Bug
>          Components: resolver
>    Affects Versions: 1.4.2
>            Reporter: Gregory Ducharme
>            Priority: Major
>         Attachments:
> 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 ( 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

View raw message