[
https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287277#comment-17287277
]
Tamás Cservenák commented on MRESOLVER-164:
-------------------------------------------
Regarding the confusion: if you look at maven-resolver
org.eclipse.aether.impl.VersionRangeResolver interface, you will find NO
implementation of it within resolver project. The reason is, well... let's have
a bit of history class here.
So, back in 2007., when Maven 2.x was the stable, the work on Maven 3 started.
From beginning it was clear, that most important and complex part of Maven 2
related to most important thing that Maven does ("declarative dependency
resolution") needs a major rework, so Maven 3 started with this area getting
"special treatment". First, the Mercury project was born (trivia: Sonatype
Nexus 1/2 still holds some code from this project, they were born
simultaneously at Sonatype). Later, a new project for same purpose, Aether got
rebooted, and Mercury dropped (side-note: Aether started as Sonatype project,
later moved to Eclipse, and today is Apache project). With that in mind, Aether
was intentionally written in "generic" fashion, it have no notion of "models",
it have no idea how to parse POM, XML like repository-metadata.xml, and so on
(and this was an intentional design decision). Also, look at AetherModule for
Guice or it's ServiceLocator, it's javadoc contains sentences like "To acquire
a complete repository system...", meaning Maven Resolver (former Aether) alone
is in some form "incomplete": it does not know (nor care) from "where" things
like descriptors, versions etc come. Hence, the maven-resolver-provider module
in Maven completes Resolver with Maven Models (so POM parsers, repository
metadata XML parser and so on, enables Aether to use maven models, to read and
write them), it basically "completes" the system.
> DefaultDependencyCollector filterVersions seems always return full version
> range
> --------------------------------------------------------------------------------
>
> Key: MRESOLVER-164
> URL: https://issues.apache.org/jira/browse/MRESOLVER-164
> Project: Maven Resolver
> Issue Type: Bug
> Affects Versions: 1.4.2, 1.6.1
> Reporter: Xiang Li
> Priority: Major
>
> Related to MNG-7049 but I think the root cause is in maven-resolver so I
> opened a new issue. Correct me if it is better to still use the old ticket.
> During using version ranges, I notice that maven will download all poms from
> a version range, which happen in that
> [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404],
> the reason is that
> [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> here seems return null. Since by default, versionFilter is set to null by
> DefaultRepositorySystemSession, and I do not see many examples that
> setVersionFilter get used for some reason.
> Another thing that confuses me is that version range is resolved by
> DefaultVersionRangeResolver in maven rather than maven-resolver here.
>
> I wonder if it possible to set HighestVersionFilter
> [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> instead of return all version range results. I am happy to contribute a PR
> with some guidance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
