arturobernalg opened a new pull request, #2261:
URL: https://github.com/apache/maven-resolver/pull/2261
Fixes #1304.
When a repository has updatePolicy=never for releases but no explicit
snapshot policy (which defaults to daily), resolving metadata of nature
RELEASE_OR_SNAPSHOT (version ranges, LATEST/RELEASE) merged the release and
snapshot update policies into one effective policy by picking whichever had the
shorter interval. "never" always lost to "daily", so every build re-fetched
maven-metadata.xml for any version-ranged dependency regardless of the
configured policy.
DefaultRemoteRepositoryManager.merge() already has this exact pattern for
checksum policies (since 2.0.23): the stronger of the two wins by default, with
a config flag to opt back into the old "weakest wins" merge. This applies the
same fix to the artifact and metadata update policies, via a new
UpdatePolicyAnalyzer.getStrongerUpdatePolicy() counterpart to the existing
getEffectiveUpdatePolicy().
Testing: updated testGetPolicy to assert the correct ("never") outcome,
which fails against the unfixed merge logic, and added three more tests
mirroring the existing checksum-policy coverage (stronger-wins default, legacy
opt-in flag, session override). Ran the full maven-resolver-impl test suite
plus checkstyle/spotless, all green.
No backport: maven-resolver-1.9.x has a single update policy shared by both
natures (no release/snapshot split), so this merge doesn't exist there.
---
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](https://www.apache.org/licenses/LICENSE-2.0)
check one of the following:
- [x] I hereby declare this contribution to be licensed under the [Apache
License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0)
- [x] I hereby declare that I have filed an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]