[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520153#comment-17520153
]
wei cai edited comment on MRESOLVER-133 at 4/10/22 11:18 AM:
-------------------------------------------------------------
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equivalent to
https://issues.apache.org/jira/browse/MNG-7049, right? We just need to fix the
unnecessary poms downloadings when comes to resolve a dependency with version
range?
The BFS + Skipper is in BFDependencyCollector, as you can see with below code,
it will do skip resolution of lower versions, however it does not help skip
pom/descriptor 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/descriptor downloadings, let's check the code:
1. 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]
2. Download all poms/descriptors 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 any of the version (newer version comes first) is resolved
successfully.
Fired initial PR for discussion:
[https://github.com/apache/maven-resolver/pull/163]
Added you access, feel free to edit the PR if you would like to modify.
Verified the patch by adding below dependency in my project and now only poms
of gson-parent and gson 2.9.0 are downloaded.
{code:java}
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>[0.0.1,3.0.0)</version>
</dependency>{code}
was (Author: wecai):
[~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 with below code,
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 successfully.
Fired initial PR:
[https://github.com/apache/maven-resolver/pull/163]
Feel free to edit the PR if you would like to modify.
Verified by adding below dependency in my project and only poms of gson parent
and gson 2.9.0 are downloaded.
{code:java}
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>[0.0.1,3.0.0)</version>
</dependency>{code}
> 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)
