[
https://issues.apache.org/jira/browse/MRESOLVER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17928017#comment-17928017
]
Bas van Erp commented on MRESOLVER-634:
---------------------------------------
[~cstamas] if there is any way we can assist with this issue, just let me know.
To give you some context: we use short-living Jenkins agents which get their
own Maven dependency cache pre-filled as to reduce the load on our central
artifact repository (Nexus). Since our dependencies don't change all that
often, this works great.
Except for these version-range artifacts. And we're dependent on a little
company that starts with an O and is owned by L.Ellison and they simply _love_
version-ranges in their POM files.
So _every single_ CI Maven build starts with retrieving these metadata files
(hundreds of them), just to proceed as normal (because no update
available/needed). Despite our {{<updatePolicy>never</updatePolicy> }}for all
agents.
> 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)
