[
https://issues.apache.org/jira/browse/MRESOLVER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922988#comment-17922988
]
Tamas Cservenak edited comment on MRESOLVER-634 at 2/1/25 7:50 PM:
-------------------------------------------------------------------
I am removing this issue from Resolver 2.0.x, as I just realized that it is
"not applicable" to it. Resolver 1.x has one update policy for remote
repositories, while Resolver 2.x did _split the update policies_ and supports
separate policy for artifacts and separate policy for metadata. See
MRESOLVER-377
was (Author: cstamas):
I am removing this issue from Resolver 2.0.x, as I just realized that it is
"not applicable" to it. Resolver 1.x has one policy remote repositories, while
Resolver 2.x did _split the policies_ and support separate policy for artifacts
and separate policy for metadata. See MRESOLVER-377
> updatePolicy is ignored for version-range metadata requests
> -----------------------------------------------------------
>
> Key: MRESOLVER-634
> URL: https://issues.apache.org/jira/browse/MRESOLVER-634
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 1.9.22
> Environment: Maven 3.9.9, Fedora & MacOS
> Reporter: Bas van Erp
> Priority: Major
> Fix For: 1.9.23
>
>
> maven-metadata.xml is refetched for every dependency which uses
> version-ranges if the {{resolver-status.properties}} file's "lastUpdated"
> property is _before_ last midnight (local time, for some reason).
> It ignores all updatePolicy configs in settings.xml
> I have tried diving into the code, but as I'm not a programmer, I couldn't
> really wrap my head around it.
> h2. Setup
> * Have a {{settings.xml}} with {{<updatePolicy>never</updatePolicy>}} for
> everything.
> * Have a {{pom.xml}} with a dependency which uses a version-range.
> * Run {{mvn validate}} to trigger the resolver and make sure all metadata
> and dependencies are downloaded and the Maven cache is warmed up.
> h2. Correct
> * Use [https://www.epochconverter.com/] to create a millisecond timestamp
> for *today* (local-time): 00:00:01
> * Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
> {{resolver-status.properties}} file of the dependency which is referenced in
> the pom.xml
> * Run {{mvn validate -X}} to trigger the resolver. It should return
> something like: "Skipped remote request for x:y/maven-metadata.xml, locally
> cached metadata up-to-date"
> * Good
> h2. Wrong
> * Use [https://www.epochconverter.com/] to create a millisecond timestamp
> for *yesterday* (local-time): 23:59:59
> * Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
> {{resolver-status.properties}} file of the dependency which is referenced in
> the pom.xml
> * Run {{mvn validate}} to trigger the resolver.
> * The resolver will download the maven-metadata.xml again. Every day.
> h2. Impact
> We have some dependencies which use version ranges for a lot of transitive
> dependencies, and I hate it for multiple reasons. But to add insult to
> injury, every night the first build will refetch all these metadata files in
> order to see if version resolution needs to change. ;)
> I have found no way to block this, since version-ranges seem to bypass
> repository updatePolicy settings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
