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]

Reply via email to