[
https://issues.apache.org/jira/browse/MRESOLVER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930313#comment-17930313
]
Tamas Cservenak edited comment on MRESOLVER-634 at 2/25/25 12:53 PM:
---------------------------------------------------------------------
[~bverp] After reconsidering, I still think that the issue is wrong, or in
other words, your problem should be addressed differently, than making Maven
metadata "never" update. Let me explain what happens, but before allow me a bit
of a digression: As you know, we are maintaining two Resolver versions (1.x and
2.x) that are used in Maven 3 and Maven 4 respectively. One of the differences
between Resolver 1.x and 2.x is that 1.x "implicitly" does these "daily
updates" to metadata (as you discovered), while in 2.x we introduced split
policies, and we have two of them: artifact policy and metadata policy. But
still, IMO, you would be interested in prod solution (Maven 4 is far not prod,
is not GA 4.0.0), but more importantly, making metadata updates "never" is not
what you want.
Related doco: https://maven.apache.org/repositories/metadata.html
First, Maven has 3 kind/types of metadata, G level, A level and V level. G
level is used to resolve Plugins (prefix -> A), A level is used to discover
versions (ranges but also "latest" plugin version, see G level metadata) and V
level is used to resolve SNAPSHOTs (when you write 1.0-SNAPSHOT to resolve it
to latest "timestamped" snapshot). Second, update policy is applied once the
content is downloaded.
Story: You start with empty local repository. You invoke {{mvn myplugin:goal}},
and as local repo is empty, Maven will download G level metadata for configured
plugin group (assume plugin is in-house, company plugin, but same stands for
ANY plugin in fact), then download A metadata, resolve latest version and
download and invoke mojo. Then, next day, assume you in-house decide to create
other "myotherplugin", so you develop it, build it, release and deploy it. And
now, you want {{mvn myotherplugin:goal}}. Given G metadata is already present,
and assuming your "never" policy is applied to metadata, Maven would fail here,
as it did download from remote repository G metadata while {{myotherplugin}}
was not yet deployed. But same stands for A metadata: once you "fix" G
metadata, and prefix is found, A metadata would need "fix" to pick up latest
version, like the version you just deployed today. Due policy, Maven would not
retry, would consider metadata "immutable". Hence, the prefix {{myotherplugin}}
would not be discovered. (and very same story stands for snapshot resolution as
well, Maven would download once, and stop getting info about later daily
deploys).
Can you do something like in this reproducer?
https://github.com/cstamas/MRESOLVER-634
Explanation to reproducer:
* dependency is the artifact produced by O-prefixed company and uses range
* dependant is your project, suffers from ranges as it depends on dependency
* dependant-fix prevents range requests totally
was (Author: cstamas):
[~bverp] After reconsidering, I still think that the issue is wrong, or in
other words, your problem should be addressed differently, than making Maven
metadata "never" update. Let me explain what happens, but before allow me a bit
of a digression: As you know, we are maintaining two Resolver versions (1.x and
2.x) that are used in Maven 3 and Maven 4 respectively. One of the differences
between Resolver 1.x and 2.x is that 1.x "implicitly" does these "daily
updates" to metadata (as you discovered), while in 2.x we introduced split
policies, and we have two of them: artifact policy and metadata policy. But
still, IMO, you would be interested in prod solution (Maven 4 is far not prod,
is not GA 4.0.0), but more importantly, making metadata updates "never" is not
what you want.
Related doco: https://maven.apache.org/repositories/metadata.html
First, Maven has 3 kind/types of metadata, G level, A level and V level. G
level is used to resolve Plugins (prefix -> A), A level is used to discover
versions (ranges but also "latest" plugin version, see G level metadata) and V
level is used to resolve SNAPSHOTs (when you write 1.0-SNAPSHOT to resolve it
to latest "timestamped" snapshot). Second, update policy is applied once the
content is downloaded.
Story: You start with empty local repository. You invoke {{mvn myplugin:goal}},
and as local repo is empty, Maven will download G level metadata for configured
plugin group (assume plugin is in-house, company plugin, but same stands for
ANY plugin in fact), then download A metadata, resolve latest version and
download and invoke mojo. Then, next day, assume you in-house decide to create
other "myotherplugin", so you develop it, build it, release and deploy it. And
now, you want {{mvn myotherplugin:goal}}. Given G metadata is already present,
and assuming your "never" policy is applied to metadata, Maven would fail here,
as it did download from remote repository G metadata while {{myotherplugin}}
was not yet deployed. But same stands for A metadata: once you "fix" G
metadata, and prefix is found, A metadata would need "fix" to pick up latest
version, like the version you just deployed today. Due policy, Maven would not
retry, would consider metadata "immutable". Hence, the prefix {{myotherplugin}}
would not be discovered. (and very same story stands for snapshot resolution as
well, Maven would download once, and stop getting info about later daily
deploys).
Can you do something like in this reproducer?
https://github.com/cstamas/MRESOLVER-634
Explanation to reproducer:
dependency is the artifact produced by O-prefixed company and uses range
dependant is your project
dependant-fix prevents range requests totally
> 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
>
> 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)
