[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181997#comment-17181997
]
Michael Osipov commented on MRESOLVER-133:
------------------------------------------
OK, I went through. Case 1 and 3 are *not* identical The second one does delete
version 1. Please look closely at case 2: {{demo.sh 1}}. Module-1, v1 requires
parent, v1 which is not present. I assume your stance is that: If from
{{maven-metadata.xml}} a higher version is as requested from the range, don't
download the lower bound of the range because a newer one is available. So it
should go straight to version 2 w/o even touching version 1 at all.
If so, I don't consider that as a bug, but merely as weakness because nothing
is broken. I recommend setting a breakpoint in
{{org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange(RepositorySystemSession,
VersionRangeRequest)}} and try to analyze this. I am quite certain that when
versions are resolved, it tries to read all metadata in
{{org.apache.maven.repository.internal.DefaultVersionRangeResolver.readVersions(RepositorySystemSession,
RequestTrace, Metadata, ArtifactRepository, VersionRangeResult)}}.
> Maven dependency fails if the parent entire history cannot be resolved.
> -----------------------------------------------------------------------
>
> Key: MRESOLVER-133
> URL: https://issues.apache.org/jira/browse/MRESOLVER-133
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
> Affects Versions: 1.4.2
> Reporter: Gregory Ducharme
> Priority: Major
> 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)
