Skip to content

Augment version range resolution used repositories #2575

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Jul 7, 2025
Merged

Augment version range resolution used repositories #2575

merged 2 commits into from
Jul 7, 2025

Conversation

cstamas
Copy link
Member

@cstamas cstamas commented Jul 4, 2025 •
edited
Loading

Ability to control which repositories to be queried to resolve ranges. Introduced new property: maven.versionRangeResolver.natureOverride that is used in VersionRangeResolver, and means:

  • not set; behave as before (default)
  • "auto" string; will check lower and upper bounds, and if any is snapshot, will querty snapshot reposes otherwise not
  • any valid value of resolver Metadata.Nature enum; then will use that

Fixes: #2558

@cstamas
Ability to control which repositories to be queried to resolve ranges…
1b2a2d3 
…. Introduced new property:

`maven.versionRangeResolver.natureOverride` that is used in VersionRangeResolver, and means:
* not set; behave as before (default)
* "auto" string; will check lower and upper bounds, and if any is snapshot, will querty snapshot reposes otherwise not
* any valid value of resolver Metadata.Nature enum; then will use that

Fixes: apache#2558
@cstamas cstamas requested a review from gnodet July 4, 2025 17:16
@cstamas cstamas self-assigned this Jul 4, 2025
@cstamas cstamas changed the title Ability to control which repositories to be queried to resolve ranges Augment version range resolution used repositories Jul 4, 2025
@cstamas cstamas added this to the 4.1.0 milestone Jul 4, 2025
@cstamas cstamas added the enhancement New feature or request label Jul 4, 2025
@cstamas cstamas marked this pull request as ready for review July 4, 2025 17:45
@gnodet gnodet added mvn3 and removed mvn3 labels Jul 4, 2025
slawekjaranowski
slawekjaranowski reviewed Jul 6, 2025
View reviewed changes
api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java
* <li>"snapshot" - query only snapshot repositories to discover versions</li>
* </ul>
* Default (when unset) is existing Maven behaviour: "release_or_snapshots".
* @since 4.0.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4.1.0 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnodet this needs backport to 4.0.0, but do I need to backport it manually or we have some automation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and is 4.0.0 as if you check #2574 the property is different: 3.x uses 3.x "way of naming", and 4.x already had maven.versionResolver... so this introduced maven.versionRangeResolver... prop

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnodet this needs backport to 4.0.0, but do I need to backport it manually or we have some automation?

We don't. I haven't been able to setup something that would work without a global GH access token as a secret. I may have missed something though.
Anyway, I've been using backport so far.

@cstamas cstamas merged commit 37b0699 into apache:master Jul 7, 2025
1 check passed
@cstamas cstamas deleted the range-resolution branch July 7, 2025 11:03
cstamas added a commit to cstamas/maven that referenced this pull request Jul 7, 2025
@cstamas
Augment version range resolution used repositories (backport)
08de648 
Ability to control which repositories to be queried to resolve ranges. Introduced new property: (apache#2575)

Ability to control which repositories to be queried to resolve ranges. Introduced new property: `maven.versionRangeResolver.natureOverride` that is used in VersionRangeResolver, and means:
* not set; behave as before (default)
* "auto" string; will check lower and upper bounds, and if any is snapshot, will querty snapshot reposes otherwise not
* any valid value of resolver Metadata.Nature enum; then will use that

Fixes: apache#2558
Backport of master 37b0699
@cstamas cstamas mentioned this pull request Jul 7, 2025
Merged
cstamas added a commit that referenced this pull request Jul 7, 2025
@cstamas
Augment version range resolution used repositories (backport) (#10890)
7deffd2 
Ability to control which repositories to be queried to resolve ranges. Introduced new property: (#2575)

Ability to control which repositories to be queried to resolve ranges. Introduced new property: `maven.versionRangeResolver.natureOverride` that is used in VersionRangeResolver, and means:
* not set; behave as before (default)
* "auto" string; will check lower and upper bounds, and if any is snapshot, will querty snapshot reposes otherwise not
* any valid value of resolver Metadata.Nature enum; then will use that

Fixes: #2558
Backport of master 37b0699
@ctubbsii
Copy link
Member

ctubbsii commented Jul 9, 2025

Two questions:

  1. Shouldn't auto be default instead of release_or_snapshot? I can't imagine this is really fixing anything if it defaults to using all the snapshot-only repos. Very few people are going to change the default in their maven config (tyranny of the default). Also, it's a bit confusing semantically that a specific implementation is the default behavior, but "automatic" is not, since "automatic" is typically thought of as a behavior that employed when a more specific narrow behavior is not selected.
  2. Is there any effort or desire to get this fixed in 3.9? That's where it was first observed, and where most people are going to continue to be affected, I think.

@gnodet
Copy link
Contributor

gnodet commented Jul 9, 2025

Two questions:

  1. Shouldn't auto be default instead of release_or_snapshot? I can't imagine this is really fixing anything if it defaults to using all the snapshot-only repos. Very few people are going to change the default in their maven config (tyranny of the default). Also, it's a bit confusing semantically that a specific implementation is the default behavior, but "automatic" is not, since "automatic" is typically thought of as a behavior that employed when a more specific narrow behavior is not selected.

I suppose the value could be changed in 4.1.0 to be more intuitive. I'm not sure we want to change the default behavior in 3.9.x at least.

  1. Is there any effort or desire to get this fixed in 3.9? That's where it was first observed, and where most people are going to continue to be affected, I think.

It looks like #2574 ...

@ctubbsii
Copy link
Member

I'm not sure we want to change the default behavior in 3.9.x at least.

I don't know. I think more people would benefit from the default being automatic, which is more intuitive. It seems that this is not likely to hurt anybody, only benefit. I'm not expecting to use 4.x any time soon at all. So, I really only care about 3.9 right now... that's where it's likely going to continue to be the biggest problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gnodet gnodet gnodet approved these changes

@slawekjaranowski slawekjaranowski slawekjaranowski left review comments

Assignees

@cstamas cstamas

Labels
enhancement New feature or request
Projects
None yet
Milestone
4.1.0
Development

Successfully merging this pull request may close these issues.

Resolving release version ranges causes snapshot repositories to be queried for metadata
4 participants
@cstamas @ctubbsii @gnodet @slawekjaranowski